Red Hat Bugzilla – Bug 521414
dep resolution error, pam missing coreutils, triggered by mach
Last modified: 2014-01-21 01:14:45 EST
Description of problem:
The pam %post scriptlet is failing due to missing dependencies found in coreutils under certain conditions (such as those found when trying to init the mock build system for epel5-i386 on an x86_64 system)
The description of the mock issue can be found at in Bug 508211
Unfortunately this issue is a bit tricky to reproduce, it seems to depend on specific versions of lots of packages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
0. I think this needs to be done on an x86_64 machine
1. Create a minimal /tmp/testroot/yum/yum.conf with two repos http://mirrorlist.centos.org/?release=5&arch=i386&repo=os and
2. yum -v --installroot /tmp/testroot/ install glibc-devel rpm-build
Installing pam fails with these erorrs:
/var/tmp/rpm-tmp.47234: line 6: cat: command not found
/var/tmp/rpm-tmp.47234: line 7: rm: command not found
/var/tmp/rpm-tmp.47234: line 22: install: command not found
/var/tmp/rpm-tmp.47234: line 25: install: command not found
error: %post(pam-0.99.6.2-4.el5.i386) scriptlet failed, exit status 127
which seems natural since coreutils gets installed after pam.
If all the rpm-build deps gets installed but not rpm-build 85 packages instead of 86 gets installed, coreutils gets installed before pam and post doesn't fail
- If I install the 86 packages manually with rpm this issue does not manifest itself.
- If I don't enable the updates repo the bug does not manifest itself.
(Error in the bug title, 'triggered by mach' should be 'triggered by mock')
Created attachment 359881 [details]
a list of rpm files that trigger the issue
When trying to pinpoint this I have streamlined the reproduce procedure. I have a local rpms directory with the rpms listed in the attached file all fetched from the CentOS 5 i386 repositories. The following command triggers the scriptlet failure:
rm -rf /tmp/bug
yum -y --disablerepo=* --nogpgcheck --noplugins --installroot /tmp/bug \
Created attachment 359910 [details]
python script that triggers the ordering issue as a regular user
The attached script sets up some rpms from a local directory for installation into an empty local root and checks if the pam package gets placed before the coreutils package by yum.YumBase.ts.order()
Since it doesn't actually install anything it can be run as an ordinary user.
With the help of this script I've been able to reproduce the problematic behavior on an i386 machine as well as on x86_64
Created attachment 360050 [details]
invocation of the 'rpm' program that also triggers the issue
It turns out that all that yum does is order the rpm packages that it puts into the rpm transaction in an unfortunate way. With a certain ordering of packages, rpm fails to sort coreutils before pam, which triggers the %post error.
Fun fact: Being somewhat interested in statistics I actually ran a large number of random orderings of the package list to see how common the bug-triggering ordering is and it turns out that about .3% of the total number of random list orders triggers the issue.
Since it seems I don't have the permissions to change the component of this bug to rpm I have created a new one at Bug 521769
Perhaps we should leave this one open to work around the issue in yum (by perhaps sorting the packages before installation) if a fix in rpm turns out to be hard to do?
yum is not going to implement its own transaction ordering.
If you've opened a new bug then this will close