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.
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.
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.
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.