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/
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
