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
install latest errata update and downgrade to original version
Steps to Reproduce:
1. apply errata update
2. apply previously changes
3. ldd /bin/rpm
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
Normal rpm behaviour
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
No easy answer for the reversed ordering on downgrade. Run ldconfig
after downgrading is adeqquate answer for an unusual circumstance.
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.
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
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
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.