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/
Looking forward to hearing your thoughts,
|
-- Darryl Dixon <esrever_otua@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
