Bug 53841

Summary: Proper transaction sets not used during uninstall of multiple RPMS
Product: [Retired] Red Hat Linux Reporter: Adrian Chung <adrianc>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-26 18:55:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adrian Chung 2001-09-19 18:27:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686)

Description of problem:
When two RPMs are listed on the command line as part of an 'rpm -e <1> <2>'
command, RPM doesn't figure out which should be removed last.

IE:

If packageA "Requires:" packageB:

# rpm -Uvh packageA packageB

installs packageB first, then packageA, since B depends on A.

However, 

# rpm -e <1> <2>

doesn't look at dependencies, it simply removes the two packages in the
order that they're specified in.

-- Which IMO is broken, since you can't remove A without removing B first
if you specify the packages singly on the command line, but as soon as you
specify both at the same time, order doesn't matter.

So:

# rpm -e <1> <2>

removes 1, then 2

# rpm -e <2> <1> 

removes 2, then 1.

Which breaks things if you have a %postun script that needs to be run after
packageB (which is required by packageA) is removed, but not before.

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


How reproducible:
Always

Steps to Reproduce:
1. Create two RPMS, one (packageA) which requires: the other (packageB).
2. Make sure that packageA has a %postun script in it.
3. rpm -evvv <packageA> <packageB> and observe results
4. rpm -evvv <packageB> <packageA> and observe results
	

Actual Results:  During 3., packageA's %postun gets run before packageB is
removed -- BAD.
During 4., packageA's %postun gets run after packageB is removed -- GOOD.

Expected Results:  Both 3 and 4 should yield proper and deterministic
results.

If packageA requires packageB, packageB should always be removed before
packageA.

Additional info:

Comment 1 Jeff Johnson 2001-09-20 05:14:21 UTC
Hmmm, rpm has always ordered packages when erasing.
Up to rpm-4.0.3, the forward, install ordering was
used. Now the install order is reversed.

The other subtlety is that before rpm-4.0.2,
honored only PreReq:'s for packages mentioned
on the command line. That has been fixed as well.

So what version of rpm are you using? And you
should try rpm-4.0.3 which should behave as you expected.

Comment 2 Jeff Johnson 2001-09-20 15:17:14 UTC
I just verified proper reversal of install ordering for
erasures with rpm-4.0.3-1.05

Comment 3 Adrian Chung 2001-09-26 16:39:07 UTC
This *isn't* fixed.

At least not in rpm-4.0.3-1.04 which is the latest I can find in RawHide, and running
under RH7.2 beta.

In fact, not only is it not fixed, the logic is now backwards:

As I stated before:

Steps to Reproduce:

1. Create two RPMS, one (packageA) which requires: the other (packageB).
2. Make sure that packageA has a %postun script in it.
3. rpm -evvv <packageA> <packageB> and observe results
4. rpm -evvv <packageB> <packageA> and observe results

Actual Results:  

During 3., packageA's %postun gets run before packageB is removed -- BAD.

During 4., packageA's %postun gets run after packageB is removed -- GOOD. 

Expected Results:  Both 3 and 4 should yield proper and deterministic results.

Now, however, the results from 3., and 4., are reversed, and the removal only works properly in 3., and is broken in 4.

Comment 4 Jeff Johnson 2001-09-26 18:55:36 UTC
Send me a pointer to a real world example and I'll tell
you what's going on. There isn't an rpm bug here AFAICT
(and I tried) ...

Comment 5 Jeff Johnson 2001-12-09 18:42:42 UTC
This problem is being addressed in rpm-4.1 by tsorting
dependency relations for both added/erased packages,
not just added packages.