From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-6.2.16-KRUD-perfctr2.3.6 i586) Description of problem: In RedHat Linux 7.3/i386, the /usr/lib/rpm/rpm* family is dynamically linked so that many of the executables depend on libpthread.so. This makes many rpm tasks, including --query and --verify, significantly less reliable and robust, especially during and after installation and upgrade, just when you wish to rely the most on rpm. libpthread is not yet at 1.0 release, its external interface is changing rapidly, and fundamental system tools should not rely on such risky environments. RedHat Linux 7.2/i386 did not have this dependency (/usr/lib/rpm/rpm* were static linked). Example: I had /lib/i686/libpthread.so symbolically linked to a private copy based on glibc-2.2.4-24 and containing some bug fixes. I upgraded from 7.2 to 7.3, and was left with "rpm --query" and "rpm --verify" not working, even though the anaconda upgrade "succeeded". Mechanism: my libpthread.so had _dl_cpuclock_offset as an undefined external (resides in /lib/ld-2.2.4.so), but _dl_cpuclock_offset is not in glibc-2.2.5-34, so dynamic linking libpthread.so failed after the upgrade. The upgrade did install the new /lib/i686/libpthread-0.9.so, but did not notice that libpthread.so.0 was linked to libpthread-0.9.so.mine, and did not change the symlink. Whatever the reason, having --query and --verify depend on libpthread.so is a bad idea. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. On a 7.2 system: cd /lib/i686 cp libpthread-0.9.so libpthread-0.9.so.mine rm libpthread.so.0 ln -s libpthread-0.9.so.mine libpthread.so.0 2. Upgrade from 7.2 to 7.3 3. Reboot. Notice that "/bin/sleep" and "rpm --query" don't work anymore. Actual Results: Any executable that DT_NEEDED libpthread.so.0 fails during dynamic link: _dl_cpuclock_offset missing. Expected Results: /lib/i686/libpthread.so.0 should have been pointed at the new libpthread-0.9.so [anaconda rpm bug], and it should not have mattered anyway because /usr/lib/rpm/rpmq should not depend on dynamic libpthread. Additional info:
For better or worse, rpm is no better than the bits in the operating system, pthread included Meanwhile, robustness is provided by editing /usr/lib/rpm/rpmpopt-x.y if/when necessary. Commenting out the popt aliases used to re-exec the helper binary (which is shared), re-enables the query/verify modes still present in (statically linked) /bin/rpm.