Red Hat Bugzilla – Bug 70675
openssl packaging complicates upgrades/downgrades
Last modified: 2007-04-18 12:45:12 EDT
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
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
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
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.