Bug 70675 - openssl packaging complicates upgrades/downgrades
openssl packaging complicates upgrades/downgrades
Product: Red Hat Linux
Classification: Retired
Component: openssl (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-08-03 14:59 EDT by Robert Clark
Modified: 2007-04-18 12:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-09-17 19:15:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Clark 2002-08-03 14:59:59 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.
Comment 1 John Airey 2002-09-15 17:15:23 EDT
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.
Comment 2 Oliver Schulze L. 2002-09-16 18:04:42 EDT
How about using a compat-openssl-096 naming shame?
Comment 3 Robert Clark 2002-09-17 19:14:54 EDT
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
Comment 4 Joe Orton 2002-11-25 07:55:12 EST
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.

Note You need to log in before you can comment on or make changes to this bug.