Description of problem:
Seeing this with rpm-4.2.3-10 on an x86_64 when dealing with multi-lib
packages, but almost looks like we would see the same behavior no
matter the platform or if we were dealing with multi-lib.
Anyway, have a machine with the following:
I then decide to go back to the old packages, so I run
rpm -vv -Uh --oldpackage libtiff*rpm
Which attempts to reinstall the libtiff-3.5.7-13 packages. After
completion of this task, I'm missing both /usr/lib/libtiff.so.3 and
Poking through the verbose rpm output, I see that the old packages get
installed first, running ldconfig after each installation (so the
links get created) then we start removing the -20.1 packages and I get
output like this for both the i386 and x86_64 packages:
D: fini 100755 1 ( 0, 0) 264132 /usr/lib/libtiff.so.3.5 skip
D: fini 120777 1 ( 0, 0) 14 /usr/lib/libtiff.so.3
(of course, substituting lib64 for the x86_64 case) Net result, don't
remove the libtiff.so.3.5 file, as it's owned by the freshly installed
package, but do remove the libtiff.so.3 symlink, as it's not owned by
anything. This would be all swell and dandy if we just reran ldconfig
after the package removal, instead it appears that "rpm knows best":
erase: %postun(libtiff-3.5.7-20.1) skipping redundant "/sbin/ldconfig".
So we're left with a system without /usr/lib/libtiff.so.3 and
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The option --oldpackage (and --force) has never been supported by
Red Hat or rpm afaik.
Anyways, there's a 2 line fix available to turn off skipping
ldconfig on downgrade. The same issue seen when elfutils
was released as downgrade around the 1st of the year, another
"feature" that Red Hat and rpm have never ever supported.
*** This bug has been marked as a duplicate of 139233 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.