Bug 89500 - RFE package erasures are not topologically sorted.
Summary: RFE package erasures are not topologically sorted.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
: 89740 159008 (view as bug list)
Depends On:
Blocks: FC6Blocker
TreeView+ depends on / blocked
 
Reported: 2003-04-23 16:01 UTC by Gary Benson
Modified: 2007-04-18 16:53 UTC (History)
7 users (show)

Fixed In Version: rpm-4.4.1-11
Clone Of:
Environment:
Last Closed: 2006-04-05 18:50:31 UTC
Embargoed:


Attachments (Terms of Use)
The first of two test packages (1.66 KB, application/x-rpm)
2003-04-23 16:03 UTC, Gary Benson
no flags Details
The second of two test packages (1.46 KB, application/x-rpm)
2003-04-23 16:03 UTC, Gary Benson
no flags Details

Description Gary Benson 2003-04-23 16:01:19 UTC
Description of problem:
Prereq dependencies are not honoured at erase time: it seems that rpm uninstalls
packages in the reverse of the order specified on the command line.  This may
cause %postun scriptlets to fail.

Version-Release number of selected component (if applicable):
rpm-4.1-1.06

How reproducible:
Always

Steps to Reproduce:
1. Grab the two packages attached to this bug and build them (rpmbuild --rebuild
{foo,bar}-1.0-1.src.rpm).  Note that bar prereq's foo.
2. Run 'rpm -ivh {foo,bar}-1.0-1.i386.rpm && rpm -e bar foo' to get the message:
/var/tmp/rpm-tmp.10259: line 1: /usr/bin/foo: No such file or directory
error: %postun(bar-1.0-1) scriptlet failed, exit status 127
3. Run 'rpm -ivh {foo,bar}-1.0-1.i386.rpm && rpm -e foo bar' and note that no
error occurs.

Comment 1 Gary Benson 2003-04-23 16:03:06 UTC
Created attachment 91251 [details]
The first of two test packages

Comment 2 Gary Benson 2003-04-23 16:03:52 UTC
Created attachment 91252 [details]
The second of two test packages

Comment 3 Jeff Johnson 2003-04-24 19:21:42 UTC
Ah yes, erase ordering has never been implemented in rpm.

Deferred until this gets on an rpm roadmap.

Comment 4 Paul Nasrat 2005-04-27 15:16:03 UTC
Should be in rawhide from rpm 4.4.1-11

Comment 5 Jeff Johnson 2006-01-06 15:56:52 UTC
*** Bug 89740 has been marked as a duplicate of this bug. ***

Comment 6 Ville Skyttä 2006-01-07 20:16:04 UTC
Moving blocker from bug 89740.

Comment 7 Jeff Johnson 2006-01-20 21:14:03 UTC
*** Bug 159008 has been marked as a duplicate of this bug. ***

Comment 8 Tim Nelson 2006-01-25 00:37:25 UTC
Two comments pasted from bug 89740:

One from me:
-------------
Is this going to be backported to RHEL 3?  Is that what you meant by
anticipating that it will be supported everywhere?  (RHEL3 is rpm-4.2.3-21_nonptl)
-------------

...and a more important one from Ville Skyttä 
-------------
This is still an issue as of rpm-4.4.2-11 (post-FC5test1 Rawhide) using the
specfiles from comments 1 and 2, setting FC5Blocker per Jeremy's request.
-------------


Comment 9 Ville Skyttä 2006-02-27 22:52:16 UTC
Jeremy, I'm afraid I'm missing something.

The reproducer from the initial comment and comments 1 and 2 is still valid, and
can be used to show that the erasures are not expectedly sorted.  The order in
which the packages are specified in the "rpm -e" command should not matter ("foo
bar" vs "bar foo") but rpm should order them based on dependencies in the
transaction.

# rpm -ivh foo* bar* && rpm -e foo bar
Preparing...                ########################################### [100%]
   1:foo                    ########################################### [ 50%]
   2:bar                    ########################################### [100%]
/var/tmp/rpm-tmp.17400: line 1: /usr/bin/foo: No such file or directory
error: %postun(bar-1.0-1.i386) scriptlet failed, exit status 127

This happens with rpm-4.4.1-22 on FC4 and rpm-4.4.2-15.2 on FC5t3.  bar should
be erased before foo but that's not the case here.

Comment 10 Jeff Johnson 2006-04-05 18:50:31 UTC
Fixed in rpm CVS.


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