Bug 135122 - RPM runs install scriptlets before uninstall scriptlets on updates (-U)
Summary: RPM runs install scriptlets before uninstall scriptlets on updates (-U)
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-08 20:18 UTC by Jack Perdue
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2004-10-08 20:22:49 UTC

Attachments (Terms of Use)
test foo.spec to demonstrate behavior (353 bytes, text/plain)
2004-10-08 20:20 UTC, Jack Perdue
no flags Details

Description Jack Perdue 2004-10-08 20:18:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

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:


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):

How reproducible:

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:

Comment 1 Jack Perdue 2004-10-08 20:20:02 UTC
Created attachment 104957 [details]
test foo.spec to demonstrate behavior

Comment 2 Jeff Johnson 2004-10-08 20:22:49 UTC
Yes, rpm runs install scripts before uninstall scripts.

Comment 3 Jack Perdue 2004-10-08 20:30:47 UTC
Would it be too much to ask for a link to a design document
or mailing list discussion that explains this behavior?

Comment 4 Jack Perdue 2004-10-08 23:22:45 UTC
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:


there is more info in this thread:


which points to:


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

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.

Comment 5 Jeff Johnson 2004-10-11 14:15:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.