Description of problem: After downgrade of elfutils-libelf symlink to libelf becomes broken and rpm can't be used Version-Release number of selected component (if applicable): change elfutils-libelf-0.91-3 to elfutils-libelf-0.89-1 change elfutils-0.91-3 to elfutils-0.89-1 How reproducible: install latest errata update and downgrade to original version Steps to Reproduce: 1. apply errata update 2. apply previously changes 3. ldd /bin/rpm Actual results: From rpm verbose log i can see that only postinstall phase activates ldconfig job , but postunistall script gives message of : skipping redundant "/sbin/ldconfig". That means that ldconfig was activated when two versions of libelf shared object existed in /usr/lib [root@tal root]# ldd /bin/rpm librpm-4.2.so => /usr/lib/librpm-4.2.so (0xb7588000) librpmdb-4.2.so => /usr/lib/librpmdb-4.2.so (0xb74aa000) librpmio-4.2.so => /usr/lib/librpmio-4.2.so (0xb746c000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb7464000) libelf.so.1 => not found libbeecrypt.so.6 => /usr/lib/libbeecrypt.so.6 (0xb7446000) librt.so.1 => /lib/tls/librt.so.1 (0xb7431000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7421000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0xb7412000) libc.so.6 => /lib/tls/libc.so.6 (0xb72da000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000) libelf.so.1 => not found [root@tal root]# rpm -qa | grep elf rpm: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory Expected results: Normal rpm behaviour Additional info:
What happens if you type /sbin/ldconfig as root?
If i run ldconfig after rpm transaction , everything works fine. Anyway , from strace log i can see that in postinstall phase ldconfig runs for both elfutils-libelf-0.89-1 and elfutils-libelf-0.91-3 , but since symlink to elfutils-libelf-0.91-3 created after elfutils-libelf-0.89-1 , it overwrites previously created correct link. Is it a bug in redundant "/sbin/ldconfig" checks?
Detecting when to run ldconfig precisely depends on package ordering which is different on downgrade than upgrade IIRC. No easy answer for the reversed ordering on downgrade. Run ldconfig after downgrading is adeqquate answer for an unusual circumstance.
Jeff, This seems like one of the few examples where erasure ordering would really be helpful. Am I wrong? Is there a bugzilla report for sorting erasures? If not I will write one...no patch guaranteed on it though. Cheers...james
James: This isn't a erasure ordering problem. rpm does erase before install when down-grading, watch what happens by reinstalling a pkg with --force. The ldconfig uniqification assumes install-before-erase and so does not run ldconfig correctly. The very simplest hack is, if ldconfig is ever run, run one last time at end-of-transaction. That insures ldconfig has been run, but is more than a bit hacky. A better fix is far more complicated. There's a reason (which I do not know) why erase-before-install was done, it's clear from looking at the code that it was deliberate. The reason can be rediscovered, of course; otherwise the implementation predates my maintainership.
Sorry I misunderstood the issue. I completely understand that installs happen before erases, I just thought that you were saying that problem was due some how to non-deterministic order of erasures. I obviously misinterpreted your comments (would not be the first time (-;). Actually, I think the order of install and then erase is quite good (this is a radical change of oppinion of course). Basically, it allows the erases to do far less (i.e. remove less files), and there is far less chance the system would get into a really bad state (try erasing glibc before installing the new one) for any programs spawned during the rpm transaction. cheers...james