Hi, I think the approach from Darryl is a good way to do patches as long as rpm can't do it. I will have a look at this, because we have rpm-packages around 70MB and a smaller patch rpm instead of the whole amount would be great for us here. But I agree, that the problem with the remaining patch-package after uninstall of the main package is not very nice. Perhaps this could be solved by triggers, but as far as I know, there aren't any - sadly. best regards, Johannes PS: What's the way SuSE does it? rpm-list-bounces@xxxxxxxxxx schrieb am 12.08.2004 11:11:18: > 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 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
