Proposal to (formally/easily) allowing multiple versions of the same library installable

[Hedayat Vatankhah]

Dear all,
I don't know if this has been discussed before, but I didn't find any.

Summary: I have a proposal to make it easier for maintainers to have 
multiple versions of the same library in distro (by making it 
*naturally* possible) (and with minimal maintenance overhead), and for 
users/developers to get their desired version(s) installed. Proposal in 
brief: instead of packaging libfoo as libfoo, the maintainer *can* 
package it as libfooVER (e.g. libfoo2) and create libfoo/libfoo-devel 
package which depends on libfoo2/libfoo2-devel. Now, libfoo-3 package 
can be packaged as libfoo3, and both can be installed simultaneously 
(assuming that they provide different .so versions, otherwise it could 
be provided as an update to libfoo2). Notice that once libfoo2 is in the 
repos, newer versions (libfoo3/libfoo4)  should not require a package 
review.

Introduction: As a developer, it happened to me a lot to *wish* my 
Fedora version could also have a newer version of libfoo, and I'm not 
forced to either upgrade to/wait for the next Fedora release or install 
the package just to get a newer version. Also, I've seen many situations 
in which I or another user wanted to have multiple versions of the same 
library installed (e.g. to run some third party programs).
Currently, this is not possible in Fedora because RPM doesn't allow you 
to install multiple versions of the same package (e.g. libfoo). But, 
this has been workaround from time to time for some libraries; a good 
example is Qt. Qt can't be easily upgraded to version 5 since many 
fundamental packages (e.g. KDE) depend on it, but if Fedora didn't 
provide Qt5 packages it would be left behind considerably. So, you can 
see qt5-* packages in Fedora repository (IIRC, a similar situation has 
happened for Qt3->Qt4 upgrade). However, they certainly had to review 
all such qt5 packages, and also this is a temporary solution for this 
library.

Proposal: let's make it possible to have multiple versions of the same 
library installed, as far as their .so version permits that.

1. Include the base version of the library into its package name. So, 
instead of libfoo we can have libfoo2, libfoo3, libfoo4.
2. No reviews are required for new libfooX packages (as it is not 
required right now when you update your libfoo package).
3. For each Fedora release, there is libfoo/libfoo-devel packages which 
Require the "default" version of libfoo packages for that release. For 
example, libfoo.fc20/libfoo-devel.fc20 will Require 
libfoo2/libfoo2-devel; for F21 libfoo3/libfoo3-devel and for F22/Rawhide 
libfoo4/libfoo4-devel.
4. Each Fedora release can provide at least 3 versions of libfoo. e.g. 
F21 provides libfoo3 as default libfoo, libfoo2 as compat package, and 
libfoo3 as 'latest stable version'. This should not create much burden 
for the maintainer, since he is already maintaining these 3 versions for 
different Fedora release versions. Now, he can provide all of them in 
all active Fedora releases.
5. Packages should either built against the 'default version' (build 
requiring libfoo-devel), or the next version if strictly needed. 
Building against 'old' version should be discouraged/forbidden. So, in 
above example, no F21 packages are allowed to be built against libfoo2, 
which is the compatibility libfoo package in F21.

For -devel packages, two methods can be allowed:
1. Simple: -devel packages conflict with each other, so while you can 
have multiple versions of libfoo installed, you can have only a single 
version of libfoo-devel installed
2. Flexible: Provide the possibility of installing multiple -devel 
versions, and a method to select the "default" one, like the 
alternatives system.

More details can be discussed, but I think it's enough for now. I want 
to see what others think about the whole idea. Details can be worked out 
if the idea seems interesting.

Q: Can't a packager do it already? Why propose it as a 'proposal'?
A: Yes, he can, but it'll be hard; mainly because he'll need to put new 
versions of the library for review. Also, I suggest it as a 'recommended 
practice' for packaging libraries.

IMHO, this method will have many advantages, and can make it much easier 
to provide COPR repositories or similar to experiment with new things on 
a stable Fedora release without affecting other installed software. 
Also, it might make it possible to install and experiment with some 
packages from Rawhide/next Fedora release directly on your current release.
As a developer, it makes the version of available libraries for 
development less bounded to Fedora version.

Regards,
Hedayat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/147f5d59/attachment.html>