Bug 70675

Summary:	openssl packaging complicates upgrades/downgrades
Product:	[Retired] Red Hat Linux	Reporter:	Robert Clark <robert3>
Component:	openssl	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.3	CC:	jorton, oliver
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-09-17 23:15:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert Clark 2002-08-03 18:59:59 UTC

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 21:15:23 UTC

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.

Comment 2 Oliver Schulze L. 2002-09-16 22:04:42 UTC

How about using a compat-openssl-096 naming shame?

Comment 3 Robert Clark 2002-09-17 23:14:54 UTC

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).

Comment 4 Joe Orton 2002-11-25 12:55:12 UTC

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.