Bug 521414 - dep resolution error, pam missing coreutils, triggered by mach
Summary: dep resolution error, pam missing coreutils, triggered by mach
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-05 15:43 UTC by Noa Resare
Modified: 2014-01-21 06:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-08 13:49:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
a list of rpm files that trigger the issue (2.63 KB, text/plain)
2009-09-05 20:23 UTC, Noa Resare
no flags Details
python script that triggers the ordering issue as a regular user (846 bytes, application/octet-stream)
2009-09-06 13:51 UTC, Noa Resare
no flags Details
invocation of the 'rpm' program that also triggers the issue (2.65 KB, application/octet-stream)
2009-09-08 09:17 UTC, Noa Resare
no flags Details

Description Noa Resare 2009-09-05 15:43:19 UTC
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):
yum-3.2.22-20.el5

How reproducible:
always

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
http://mirrorlist.centos.org/?release=5&arch=i386&repo=updates  
2. yum -v --installroot /tmp/testroot/ install glibc-devel rpm-build
3.
  
Actual results:

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.

Expected results:

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

Additional info:
- 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.

Comment 1 Noa Resare 2009-09-05 15:47:21 UTC
(Error in the bug title, 'triggered by mach' should be 'triggered by mock')

Comment 2 Noa Resare 2009-09-05 20:23:12 UTC
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 \
install rpms/*rpm

Comment 3 Noa Resare 2009-09-06 13:51:37 UTC
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

Comment 4 Noa Resare 2009-09-08 09:17:46 UTC
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.

Comment 5 Noa Resare 2009-09-08 09:43:12 UTC
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?

Comment 6 seth vidal 2009-09-08 13:49:23 UTC
yum is not going to implement its own transaction ordering.

If you've opened a new bug then this will close


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