Bug 521769 - package install reordering broken for certain input orders
package install reordering broken for certain input orders
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: packaging-team-maint
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-08 05:39 EDT by Noa Resare
Modified: 2013-03-08 09:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-08 09:48:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Invokes rpm with the curiously ordered rpm arguments (2.65 KB, text/plain)
2009-09-08 05:39 EDT, Noa Resare
no flags Details
Don't zap Requires(pre) and Requires(post) deps (502 bytes, patch)
2009-09-09 14:12 EDT, Noa Resare
no flags Details | Diff

  None (edit)
Description Noa Resare 2009-09-08 05:39:50 EDT
Created attachment 360052 [details]
Invokes rpm with the curiously ordered rpm arguments

Description of problem:
While investigating why mock won't set up an epel-5-i386 chroot on my system I found out that rpm is sometimes picky when it comes to the order in which packages to be installed is placed in the rpm transaction.

This behavior can be demonstrated using the attached script that invokes the 'rpm' command with a set of packages ordered in a particular way as it's command line arguments, installing them to an empty rpm root.


Version-Release number of selected component (if applicable):
rpm-4.4.2.3-18.el5

How reproducible:
always

Steps to Reproduce:
1. Download the package set that triggers the issue from http://rpm.resare.com/bug-reproduce/lean.tar (62meg, those rpms are all signed by the centos-5 key, feel free to pull the rpms from any centos repository)
2. Run the attached script that uses rpm to install the packages in a fresh rpm root
3.
  
Actual results:
#
49:libselinux             ########################################### [ 70%]
#
  50:pam                    ########################################### [ 71%]
#
/var/tmp/rpm-tmp.93375: line 6: cat: command not found
#
/var/tmp/rpm-tmp.93375: line 7: rm: command not found
#
/var/tmp/rpm-tmp.93375: line 22: install: command not found
#
/var/tmp/rpm-tmp.93375: line 25: install: command not found
#
fel: %post(pam-0.99.6.2-4.el5.i386) skript misslyckades, slutstatus 127
#
  51:shadow-utils           ########################################### [ 73%]
#
  52:device-mapper          ########################################### [ 74%]
#
  53:e2fsprogs-libs         ########################################### [ 76%]
#
  54:openssl                ########################################### [ 77%]
#
  55:e2fsprogs              ########################################### [ 79%]
#
  56:krb5-libs              ########################################### [ 80%]
#
  57:MAKEDEV                ########################################### [ 81%]
#
  58:findutils              ########################################### [ 83%]
#
  59:coreutils              ########################################### [ 84%]

Expected results:
coreutils should be installed before pam to satisfy it's post dependencies.

Additional info:
if you change the order of the rpm files listed in the script somewhat rpm will probably do the right thing. About 0.5% of all random input orders trigger this behavior.
Comment 1 Noa Resare 2009-09-09 13:26:10 EDT
Trying to unpack this issue and learn some about RPM internals is interesting stuff.

Basically there is a circular dependency between coreutils and pam. And rpm handles circular dependencies by removing them with depends.c:zapRelation() until the dependency graph doesn't contain any circular references. The references gets treated equally and the direction of the zapping of the dependency is dependent (heh) on where you start the traversal of the dep graph.

I believe that the right thing to do is to prioritize Requires(pre) and Requires(post) over plain Requires and I hope to understand enough of depends.c to be able to create such a patch in the near future.

On a more general note, I think that it would be a good idea to increase the predictability of failures by ordering all packages alphabetically before beginning to resolve the dependency order. That way the failure or success of a particular install would not depend on the ordering of the install items in the transaction.
Comment 2 Noa Resare 2009-09-09 14:12:53 EDT
Created attachment 360300 [details]
Don't zap Requires(pre) and Requires(post) deps 

The attached patch modifies zapRelation() not to zap Requires(pre) and Requires(post) dependencies.

This way the circular dependency will be resolved by zapping the reversed relation. Actually I think that is the correct way to do things. It will probably lead to installation failures when packages have circular pre/post dependencies, but people who construct package dependencies that way should suffer as early as possible anyway.
Comment 3 Florian Festi 2013-03-08 09:48:13 EST
There are a couple of other problems with the ordering code in rpm-4.4.2. While the proposed patch fixes this particular case it is not sufficient to solve the problem. It also breaks for loops of Requires(pre), so it would need a more elaborated handling of this case.

Later versions of rpm have this problem fixed by basically completely rewriting the ordering code. But backporting these changes is not an option.

As changing the behaviour now has a chance to trip up other problems this issue will not be addressed in this RHEL release.

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