Bug 499048
| Summary: | [Regression] RHEL 5.3 yum handles circular dependencies wrong, causes mock failures | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Robert Scheck <redhat-bugzilla> |
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | urgent | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.3 | CC: | fabian.arrotin, james.antill, kbsingh, lfarkas, robert.scheck |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-05-06 09:44:50 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: | |||
|
Description
Robert Scheck
2009-05-04 23:44:17 UTC
Re-read above with s/yum-3.2.8-9.el5_2.1/yum-3.2.19-18.el5/g please, was a copy & paste error. Without sed: - yum-3.2.8-9.el5 (RHEL 5.2) works - yum-3.2.19-18.el5 (RHEL 5.3) does not work Please verifify and fix ASAP, breaks mock builds for CentOS and RHEL all the time, unluckily. There are at least four "bugs" here: 1. Pam doesn't do the hack to make sure coreutils is installed first. 2. Yum in 5.3 fails the transaction when scriptlets fail. 3. rpm marks %post failures as a scriplet failure. 4. rpm changes it's ordering of pam/coreutils, which without #1 it is entitled to do. ...the way this was "fixed" in Fedora was to have rpm not mark the transaction as a scriptlet failure when %post fails (fixing #3). One way to fix it for 5.3 is to fix pam (I know some people rebuilding CentOS have done this), which takes care of #1. And the other work around is: http://lists.centos.org/pipermail/centos/2009-April/075092.html ...which fixes #4. Reverting #2, which I assume is what you want given where you opened the bug, is possible ... but the least preferable IMO. I'll pass this over to Panu to see if he wants to do #3 for 5.4. Note that just adding "Requires(post): coreutils, /sbin/ldconfig" to pam does not work for me, that is IIRC the last suggestion on the CentOS mailing list thread regarding that. Interestingly, I've to downgrade yum and only yum, not rpm to get it working again. So if you tell me, that this is also a rpm issue, yum would duplicate the logic of rpm and the bug would exist twice - once in yum and once in rpm? There's a whole pile of dependency loops here, just to name a few: pam <-> coreutils <-> libselinux <-> findutils <-> coreutils This makes ordering quite a lottery, for example in this case hitting the pam %post failure depends on the exact order in which the packages are fed into the transaction: apparently that order in yum happened to change between 5.2 and 5.3. And the ordering depends on the exact set of dependencies present in the transaction, another change here is that rpm itself used to have %pre require shadow-utils which in turn depends on libselinux which is involved in the loops above... which might've masked the underlying loops in this case. The dependency loops are what really needs fixing, but it's possible to work around with adding dependency whiteout to rpm config, this seems to cure at least this particular case: %_dependency_whiteout \ coreutils>pam Well, yum from RHEL 5.2 was working. With yum from RHEL 5.3 it is no longer working, thus it is a regression. Why can't we fix the issue by undo what has been done to break it? That yum in 5.2 happens to add things to the transaction in an order that happens to work for this case is just *pure luck*. Topological sort gives different ordering when the input changes, but those orders are correct if the input (dependencies in this case) are correct. The dependencies need fixing, not yum or rpm. this bug is the same as #497570 *** This bug has been marked as a duplicate of bug 497570 *** |