Bug 521414
Summary: | dep resolution error, pam missing coreutils, triggered by mach | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Noa Resare <noa> |
Component: | yum | Assignee: | James Antill <james.antill> |
Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.4 | ||
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-08 13:49:23 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: | |||
Attachments: |
Description
Noa Resare
2009-09-05 15:43:19 UTC
(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 \
install rpms/*rpm
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 |