Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: rpm runs the %pre and %post scripts before the %preun and %postun scripts when doing an upgrade with -U. Personally, I think it should clean up the old before dealing with the new. This could be a duplicate of: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89740 but I'm not sure. At the very least, I'd like some explanation of the present behavior and why the behavior I propose would be improper. Version-Release number of selected component (if applicable): rpm-4.2.1-0.30 How reproducible: Always Steps to Reproduce: 1. download the attached foo.spec to /usr/src/redhat/SPECS 2. as root, cd /usr/src/redhat/SPECS 3. rpmbuild -ba foo.spec # initial version 4. rpmbuild -ba foo.spec # upgrade version 5. rpm -i ../RPMS/i386/foo-[initialversion].i386.rpm 6. rpm -U ../RPMS/i386/foo-[upgradeversion].i386.rpm Actual Results: For steps 5 and 6... [root@silverstreak SPECS]# rpm -i ../RPMS/i386/foo-0-1097260060.i386.rpm pre script post script [root@silverstreak SPECS]# rpm -U ../RPMS/i386/foo-0-1097260063.i386.rpm pre script post script preun script postun script Expected Results: On the upgrade, the ordering should have been: preun script postun script pre script post script Additional info:
Created attachment 104957 [details] test foo.spec to demonstrate behavior
Yes, rpm runs install scripts before uninstall scripts.
Would it be too much to ask for a link to a design document or mailing list discussion that explains this behavior?
Since some at Redhat seem more prompt in shutting this issue down instead of shedding some light on the situation, I'll provide links to a workaround and information for the next poor soul who might offer up a suggestion to a improve a supposedly "community-developed" project. I could understand, and am quite use to, such a response to bug reports in Redhat "products" but I thought Fedora was a "community developer project" and not a "product". If someone at Redhat doesn't want to do it, fine... but that isn't a reason to close it. If "that is the way it is" just because "that is the way it is", then I think a request to change its behavior is reasonable. If it is that way because it has to be that way, then it would be nice to know why. A search of the term "triggerin" at redhat.com returns nothing in terms of documentation... all the relevant info is hidden in some secret email archive somewhere... provided you know to look for "triggerin". This is a workaround: http://www-106.ibm.com/developerworks/linux/library/l-rpm3.html?dwzone=linux there is more info in this thread: http://lists.freshrpms.net/pipermail/freshrpms-list/2002-November/002202.html which points to: /usr/share/doc/rpm-4.2.1/triggers as a reference, but neither explains why it is done this way and why it wouldn't be better, given a community of developers not under bound by any business decisions on what upgrades should go into what releases, to do the more logical thing and take care of the uninstall scripts first. Like I said, I'm quite used to bugs being ignored or closed for Redhat products, but since this supposed to be the Fedora project, I'm a bit suprised that it tool only 2-minutes to decide that this issue should be closed.
Therea are no design documents because rpm has always done install before erase, has never done anything else, and the behavior is unlikely to ever change no matter what reasons are supplied. The basic reasoning is to narrow windows when shared libraries that are being upgraded are replaced so that upgrades are likelier to be reliable on live systems. A remove-before-erase policy leaves a quite large window until the new shared library is replaced. Current rpm behavior writes the new shared libraray to a temp file, then renames the library into place.