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
Version-Release number of selected component (if applicable):
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
[root@silverstreak SPECS]# rpm -U ../RPMS/i386/foo-0-1097260063.i386.rpm
Expected Results: On the upgrade, the ordering should have been:
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
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.
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.