Bug 136456

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:
libtiff-3.5.7-20.1.i386
libtiff-3.5.7-20.1.x86_64
libtiff-devel-3.5.7-20.1.x86_64

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
/usr/lib64/libtiff.so.3

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
/usr/lib64/libtiff.so.3.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: