Description of problem: When I read the message which explained that sshd was having I problem with openssl-0.9.7f-1 and to simply back off to openssl-0.9.7e-3, I thought I would give it a try. I was surprised when lots of things stopped working because libssl.so.5 did not exist. I tracked the problem down to the fact that installing openssl-0.9.7e-3 with --oldpackage had resulted in the sym-links not being updated. When I finally did install openssl-0.9.7f-3 the sym-links were updated. Version-Release number of selected component (if applicable): rpm 4.4.1-9, openssl 0.9.7f-3 and openssl 0.9.7e-3 How reproducible: yes. Steps to Reproduce: 1. update to "current" openssl in development 2. then rpm -Uvh --oldpackage from FC4T1 initial distribution 3. ls -l /lib/libssl* /lib/libcrypto* /lib64/libssl* /lib64/libcrypto* Actual results: hanging sym-links for libssl.so.5 and libcrypto.so.5 Expected results: symlinks updated to point to currently installed libraries Additional info: I believe this is an rpm problem but it also could be a packaging problem with openssl. The system used was x86_64 although I expect it to be the same on a i386 system.
RPM does not support downgrades as with --oldpackage.
I just hit the same problem downgrading my glib2 from rawhide back to Fedora 9 after I finished testing a program that needed the rawhide version. When I logged out of GNOME, gdm died and I had to run ldconfig manually from the terminal. What is the purpose of --oldpackage if not for downgrades? It seems to me that the problem could be fixed easily by letting ldconfig run a second time after the erasures are complete. I understand that the symlinks will still be broken during the erasures (the only way to fix that would be for rpm to somehow indicate its planned shared library deletions to ldconfig before actually performing them), but that's better than leaving them broken forever.