Red Hat Bugzilla – Bug 433579
Requires(post) does not bring in library dependencies at the right time
Last modified: 2014-01-12 19:07:02 EST
Description of problem: I'm doing a livecd build against rawhide. I'm seeing the following messages during install: Installing: tcsh ################### [ 322/1182]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: mlocate ################### [ 384/1182]/bin/grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: coreutils ################### [ 415/1182]/bin/grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: fontconfig ################### [ 417/1182]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: rpm ################### [ 437/1182]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: nss_ldap ################### [ 558/1182]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: initscripts ################### [ 591/1182]fgrep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: torque ################### [ 643/1182]/bin/grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: microcode_ctl ################### [ 658/1182]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory Installing: pcre ################### [ 675/1182] Now, tcsh has: Requires(post): grep and grep has a requirement on libpcre.so.0, but pcre isn't getting installed until later in the transaction. Version-Release number of selected component (if applicable): rpm-4.4.2.2-13.fc9
I'm seeing these now in regular anaconda installs of rawhide: Installing coreutils-6.10-16.fc9.i386 /bin/grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory coreutils does a: Requires(post): grep So it is doing the right thing by requiring grep, but not all of grep's dependencies are installed yet. rpm-4.4.2.3-0.5.rc1.i386 I really think this should be a release blocker as this could leave the installed system in a strange state if %post scripts fail strangely.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is there any trick that puts pcre earlier in the installation?
No tricks, just standard distro QA. tcsh has Requires(post): grep grep has Requires: libpcre.so.0 pcre has Provides: libpcre.so.0 If pcre-7.3-3.fc9 is not installed before grep-2.5.1-59.fc9, which is installed before tcsh-6.15-4.fc9, then either 1) there are dependency loops (which cause the above dependencies to be ignored while ordering). 2) something else has been broken in rpm-4.4.2.3-2.fc9
How do I tell if it is 1) or 2)? And more specifically, how do I fix the problem? As it is now, I can't rebuild a Live-CD with a changed package list. During installation of the rpm package I get: Installing: rpm ################### [ 756/1730]grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory During the Live-CD %post section I get errors from rpm: rpmdb: Program version 4.3 doesn't match environment version error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora: import failed. I have a manual installation of the Sun Java JRE .rpm, this fails with the same error message. I assume that these errors are due to the fact that the post script of the rpm installation hasn't been run. How do I fix this problem?
I'm still seeing this building a livecd on current rawhide: Installing: tcsh ################### [ 172/1215] grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory pcre is finally installed later: Installing: pcre ################### [ 535/1215]
This bug has been triaged
A new manifestation: Installing bash-3.2-28.fc10.x86_64 /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory warning: %post(bash-3.2-28.fc10.x86_64) scriptlet failed, exit status 127
Interestingly, all of the other pcre messages are now gone. Perhaps coincidence, perhaps related.
While I think this is a bit of a pile-on bug, the current issue with the bash circular dep is one that concerns me for F10 Preview, so I'm adding it to the blocker.
Yes this is starting to be way too much of a pile-on bug... so lets forget about the older issues that apparently are gone now (as per comment #9), the pcre thing was almost certainly a dependency loop somewhere too. Most likely this recent bash change: https://www.redhat.com/archives/fedora-extras-commits/2008-October/msg06379.html -Requires(post): ncurses Removing the (post) bit removes the hint that rpm needs for correctly snipping the dependency loop. And over to bash. Oh and FWIW, bash being one of those early "bootstrap" packages, it's %post would be prime candidate for using the embedded Lua for it's actions, it'd avoid these kind of issues completely as -p <lua> doesn't need any external dependencies to work.
*** Bug 468827 has been marked as a duplicate of this bug. ***
I'm adding back the Requires(post) on ncurses-libs since that's what we actually need in %post. Easier than re-writing it in LUA, which could be done post-f10. Build going into koji shortly, will need testing when done.
http://koji.fedoraproject.org/koji/taskinfo?taskID=909965 has the build if anybody wants to try and verify it.
Verified fixed, and now tagged for F10.
*** Bug 468923 has been marked as a duplicate of this bug. ***
This one popped up again: The same build, tried 3 times: http://koji.fedoraproject.org/koji/taskinfo?taskID=1090126 http://koji.fedoraproject.org/koji/taskinfo?taskID=1090168 http://koji.fedoraproject.org/koji/taskinfo?taskID=1090184 reopening the bug...
I got some help and replaced the %post in bash with a <lua> script so that bash doesn't require anything external. I think I forgot to remove the Requires(post) but that's OK for now. The buildsystem is again functional. It had stopped working because we upgraded to a yum that treated errors in %post as fatal.