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

[Jamie Duncan]

Don't containers already accomplish this same concept? 

jduncan 

----- Original Message -----

From: "Hedayat Vatankhah" <hedayat.fwd at gmail.com> 
To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org> 
Sent: Friday, February 13, 2015 6:51:17 AM 
Subject: Proposal to (formally/easily) allowing multiple versions of the same library installable 

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 

-- 
devel mailing list 
devel at lists.fedoraproject.org 
https://admin.fedoraproject.org/mailman/listinfo/devel 
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/f3369489/attachment.html>