| From: | Rudi Chiarito |
| Date: | 28 Aug 2000 at 14:56:34 |
| Subject: | Re: RPMs (Was: AMIOPEN: quake & doom) |
On Mon, Aug 28, 2000 at 11:03:15AM +0200, Aaron Optimizer Digulla wrote:
> Sounds nice. Just keep in mind, though: The *real* reason why this
> is against RPMs philosophy is that RPM doesn't support any techniques
> which might break (ie. when you create an RPM from the sources, then
I know. I've tried everything possible to play by the rules. They might
seem draconian in a few occasions, but they're there anyway and should be
followed, even if one doesn't agree completely with RH's rationale. We're
nice and don't mess work carefully done by others (in this case, RPM's
database on the target machine). ;)
> a new, clean build). I also don't see any reason why package x.y +
> patch to x.y+1 should be != package x.y+1 but you might consider this
> when thinking about taking "short cuts" (which might cut users in
> a short time) :-)
Indeed, the purpose of the tool is, in the end, to create a patch such
that package(x.y) + patch(x.y, x.y+1) == package(x.y+1), where "==" means
"identical on a file by file basis". Of course, it's going to be very
difficult also to clone RPM metadata such as the build date and the build
host. ;)
I've added several sanity checks and will add regression tests. In these
cases one is never paranoid enough.
It's probably a good idea, BTW, to tag the patched version in some way,
so that during troubleshooting it can be identified as being different
from the full package, although from a functional point of view they HAVE
to behave just the same.
Imagine a patch which doesn't bring the system to the exact same state as
a complete install of the new package; if it's indistinguishable from the
full package, it's going to take some time before you suspect that it's
the patch at fault.