On Thursday 12 August 2004 05:20 am, johannes.grumboeck@xxxxxxxxxxxxx wrote: > 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. > Why wouldn't triggers work? I use them to perform all sorts of functions. If a rpm is uninstalled, then the patch's trigger section can perform rpm -e packagename-patch %triggerun -- packagename rpm -e packagename-patch > 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 -- Scot Mc Pherson scot@xxxxxxxxxxxxxxxxxxxx Sarasota, Florida, USA MSN: behomet@xxxxxxxxxxxxx AIM: scotlfs ICQ: 342349 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
