Bug 497570 - %post dependencies sometimes not resolved correctly
%post dependencies sometimes not resolved correctly
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: Tomas Mraz
: 499048 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-04-24 15:08 EDT by Steve Feehan
Modified: 2009-09-02 07:24 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:24:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Feehan 2009-04-24 15:08:24 EDT
Description of problem:

This issue was found in CentOS 5.3, though I suspect it is also an issue for RHEL as the pam package is not modified.

In some cases (ex. when building a chroot via mock) rpm gets the dependency ordering wrong for pam. pam's %post depends on coreutils, but the dependency is stated as: 

  Prereq: coretutils

rather than the more accurate:

  Requires(post): coreutils

Version-Release number of selected component (if applicable):

The issue exists in at least pam-

How reproducible:

Create a mock chroot for i386 with mock from EPEL (for some reason, it doesn't appear to affect real installs, or the x86_architecture).

Additional info:

See this thread for additional info:

Comment 1 Gareth Armstrong 2009-04-27 12:56:26 EDT
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
Comment 2 Tomas Mraz 2009-04-27 14:03:59 EDT
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.
Comment 3 Steve Feehan 2009-04-27 15:40:03 EDT
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.


[1] http://www.mail-archive.com/centos@centos.org/msg34765.html
Comment 4 Levente Farkas 2009-04-27 17:21:20 EDT
i also confirm that adding:
Requires(post): coreutils, /sbin/ldconfig
solves the problem.
Comment 5 Gareth Armstrong 2009-04-28 06:01:17 EDT
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,

Comment 6 Björn Gerhart 2009-04-29 11:15:18 EDT
I also confirm that the modified Requires by Gareth work in our environment.
Tested with modified version of pam-
Comment 7 Jack Neely 2009-04-30 14:51:56 EDT
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.
Comment 9 Panu Matilainen 2009-05-06 05:44:50 EDT
*** Bug 499048 has been marked as a duplicate of this bug. ***
Comment 10 Robert Scheck 2009-05-08 11:32:08 EDT
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-
Comment 14 errata-xmlrpc 2009-09-02 07:24:37 EDT
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.


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