Bug 497570
Summary: | %post dependencies sometimes not resolved correctly | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Steve Feehan <sfeehan> |
Component: | pam | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | fabian.arrotin, gareth.armstrong, gerhart, jjneely, lfarkas, ohudlick, pasteur, redhat-bugzilla, robert.scheck, sgrubb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-02 11:24:37 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
Steve Feehan
2009-04-24 19:08:24 UTC
I can confirm this behaviour on Rhel5.3 with mock 0.9.14. I would even suggest that the patch be expanded as follows: Requires(pre): grep Requires(post): mktemp, sed, coreutils, /sbin/ldconfig Requires(postun): /sbin/ldconfig Are you sure this would fix the problem in the install? I don't think so because the same issue appears with fixed pam in Fedora 8 and later. For some reason (possibly some new circular dependencies in the installed packages) the pam is now installed later in a transactions than before. This is not a regression in pam and I don't think change from Prereq to more correct Requires(pre) and Requires(post) will improve the ordering. You can try to patch it on your own and create a repo with the patched pam package, I'd like to see whether this will improve the situation. Yes, I did the original simple "Requires(post): coreutils" and it worked around the issue. I admit something is strange, as non mock installs get the ordering right, and x86_64 installs (both mock, and anaconda) get the ordering right as well. I should've pointed out in the original report that building i386 chroots on x86_64 exhibits the bug. I haven't tried creating i386 on i386. In the thread I referenced earlier, there is mention[1] of downgrading rpm to the 5.2 version fixing (or avoiding?) the problem. I haven't tried this, as downgrading rpm is not really feasible for us. If it would be helpful, I can show the installation order for various situations. Or if there is any other info I can provide, please let me know. Thanks, Steve [1] http://www.mail-archive.com/centos@centos.org/msg34765.html i also confirm that adding: Requires(post): coreutils, /sbin/ldconfig solves the problem. I can also confirm that adding the following the pam.spec file works: Requires(pre): grep Requires(post): mktemp, sed, coreutils, /sbin/ldconfig Requires(postun): /sbin/ldconfig As Steve points out above, I also should have mentioned that I observed the behaviour when try to build a srpm in a Rhel5.3 i386 mock chroot on a Rhel5.3 x86_64 hosts. x86_64 mock builds on the same host work fine. If I can provide info please hesitate to contact me. I will try and reproduce the on a Rhel5.3 i386 host this afternoon. Many thanks, Gareth I also confirm that the modified Requires by Gareth work in our environment. Tested with modified version of pam-0.99.6.2-4. I'd like to confirm as well that the suggested additions to pam.spec correct this issue for me. I'm going to use this as the production pam package at my shop. *** Bug 499048 has been marked as a duplicate of this bug. *** Panu, when will an official fix for this bug get rolled out? As we all know this is an annoying issue, that should get fixed and it is easily to solve, nevertheless currently, now it's a regression from 5.2 (working) to 5.3 (non- working). An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1358.html |