The way openssl is currently packaged, upgrading to a newer version also requires the installation of a compatibility package. e,g, upgrading from openssl-0.9.6 to openssl-0.9.6b requires the simultaneous installation of openssl096-0.9.6 for backward compatability. This is non-intuitive and makes automation of RPM upgrades very difficult. Downgrading from openssl-0.9.6b to openssl-0.9.6 (for whatever reason) is even more problematic. AFAICT, the only way to do this is to force the removal of openssl096 (leaving the system in an inconsistent state) and then downgrade openssl. A better way to package might be to split openssl into two binary packages: openssl-libs (containing the files from /usr/lib and /usr/share/doc) and openssl-utils (all other files). Then, if a newer or older version of the SSL libraries is needed, it can be installed without affecting other versions.
Why not use RedHat Network to do your upgrades with? <a href="http://rhn.redhat.com">http://rhn.redhat.com</a> I used to do manual upgrades, but even with ten systems, it became very difficult to know whether I'd installed all the upgrades I needed to.
How about using a compat-openssl-096 naming shame?
John: I'm using autorpm at the moment. Mainly because there are some packages I patch myself (e.g. kernel for XFS support) and autorpm can fetch, check the PGP signature and install these from a local server. I haven't looked at rhn much, but I don't think it can be used to keep up to date with locally produced packages(?) Oliver: I think a compat- naming scheme would have the same problem as the current one. Namely it wouldn't be obvious (to an automated RPM upgrader such as autorpm) that compat-openssl-096 is intended to replace openssl-0.9.6. This information can only come from some outside source (which is how I assume rhn handles it). It also wouldn't be possible to downgrade openssl without first forcing the removal of a compat-openssl package (which is a dependency for other packages).
This is perfectly normal for compatibility packages throughout the distribution; splitting the package into -libs and -utils etc would not make any difference to the requirement for a separate compatibility package containing the old versions of the shared libraries.