Re: Request for comments on binary RPM patch packages

[Christof Pintaske <Christof Pintaske sun com>]

Hi Daryll, All,

We are desperately looking for an upgrade mechanism for OpenOffice.org 
2.x that prevents users from downloading the whole beast again and 
again. Therefor I would highly appreciate to have a patch or update 
mechanism integrated in rpm. I really enjoy the way SuSE does it and 
would like to see that mechanism becoming mainstream.

|the problem with the "rpm --replacefiles|" approach is that two 
packages bring the same files. If you simply deinstall the original 
package your patch will remain. This is bad, but even worse if you now 
reinstall the package again both the patch and the package will appear 
in the list of installed packages, however the "real" package remains 
unpatched. Not very nice.

best regards
Christof

> Hi all,
>
>     Currently RPM doesn't (to the best of my knowledge) support the 
> concept of an 'upgrade' package that updates a package on the system 
> by only providing the files changed between that version and the 
> newest.  That is, if package foo is at version 2.1 and a new foo-2.2 
> is released, the way everybody upgrades is to get a full rpm build of 
> foo-2.2 and upgrade foo; which deletes foo-2.1 and then installs foo-2.2.
>
>     This approach is fantastically robust, but is perhaps 
> unnecessarily bandwidth-intensive; both for the entity providing 
> packages, and for people downloading them (a good example of this is 
> the amount of data in Fedora updates).  I went looking and didn't find 
> any real discussion around any proposals to modify RPM itself to 
> support the concept of a 'patch' relationship between packages, and 
> because modifying database schemas and C code is well outside my area 
> of expertise, I decided to implement a 'proof-of-concept' patching 
> tool in Python that will generate 'patch' RPMs from two 'normal' full 
> RPMs.
>
>     So my questions for the list; do we see any benefit in the idea of 
> being able to provide patch RPMs instead of full ones in all 
> situations?  Has the idea of building 'patching' semantics into RPM 
> itself been discussed previously?  Does anyone have any comments on 
> the flaws they see with the idea of externally providing patching 
> semantics on top of RPM?
>
>     For reference, the patching tool is at:
> http://freshmeat.net/projects/ruks/