Red Hat Bugzilla – Bug 50562
openssl 0.9.6 RPM removes libssl.so.0
Last modified: 2008-05-01 11:38:00 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9.1) Gecko/20010621 Description of problem: Trying to u/g from openssl-0.9.5a-14 to openssl-0.9.6-9, for libssl.so.1 and libcrypto.so.1. Newer openssl does not provide for libssl.so.0 and libcrypto.so.0 support, which are required by a large number of packages. Upgrade packages *should* be backwards compatible with versions they replace!? How reproducible: Always Steps to Reproduce: 1. Try to u/g to openssl-0.9.6-9.i386.rpm on a system which packages dependant on libssl.so.0 and/or libcrypto.so.1 Actual Results: Fails with a long list of dependancy failures, as packages require libssl.so.0, libcrypto.so.0, which are provided by openssl-0.9.5a-14, which would be superceeded by openssl-0.9.6. The latter does not provide an equivalent for these libraries (provides libssl.so.1 and libcrypto.so.1 instead). Expected Results: openssl-0.9.6 should provide equivalents for libssl.so.0 and libcryto.so.0, either symlink to versions .1 if appropriate, or keep the previous versions (reinstall). Additional info: This seems to be a common failing with replacement packages where new versions of libraries with different snames are provided. Upgrades should be backwards compatible, which includes maintaining the so snames from the previous version (either in fact or in link).
I have also run into this bug. Please let me know of a workaround if it exists.
Install the openssl095a package, which should be in the same location as the new openssl package you're attempting to install.
This definitely *is* a bug. You cannot upgrade from the older to newer openssl package -- which really should be the case, as otherwise it breaks upgrade schemes. The openssl095a package is a workaround at best -- now to upgrade you need a third package, the existance of which cannot be determined from the new package being u/g. Unless there is something in RPM which would allow this to be specified when upgrading rather than installing? But that would not work if later you had packages which required the libraries in the old package and not in the new? This is all very sloppy. RPM is a good system, so long as packages maintain their inheritance.