Bug 53841
Summary: | Proper transaction sets not used during uninstall of multiple RPMS | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Adrian Chung <adrianc> |
Component: | rpm | Assignee: | 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
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. I just verified proper reversal of install ordering for erasures with rpm-4.0.3-1.05 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. 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) ... This problem is being addressed in rpm-4.1 by tsorting dependency relations for both added/erased packages, not just added packages. |