Bug 53841 - Proper transaction sets not used during uninstall of multiple RPMS
Proper transaction sets not used during uninstall of multiple RPMS
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-19 14:27 EDT by Adrian Chung
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-26 14:55:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adrian Chung 2001-09-19 14:27:17 EDT
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 01:14:21 EDT
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 11:17:14 EDT
I just verified proper reversal of install ordering for
erasures with rpm-4.0.3-1.05
Comment 3 Adrian Chung 2001-09-26 12:39:07 EDT
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 14:55:36 EDT
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 13:42:42 EST
This problem is being addressed in rpm-4.1 by tsorting
dependency relations for both added/erased packages,
not just added packages.

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