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

Hedayat Vatankhah hedayat.fwd at gmail.com
Fri Feb 13 17:54:27 UTC 2015


/*Nikos Mavrogiannopoulos <nmav at redhat.com>*/ wrote on Fri, 13 Feb 2015 
14:11:49 +0100:
> On Fri, 2015-02-13 at 15:21 +0330, Hedayat Vatankhah wrote:
>> 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.
> I'm not against it, for the libraries which provide proper symbol
> versioning. Otherwise, if you only rely on the soname, you may end up in
> a situation where a program crashes because of inter-dependencies which
> make it link with both libfoo1 and libfoo2 which provide the same (but
> most likely incompatible) symbols.
I wonder if it should be taken care of by packages, rather than 
libraries themselves. I'm not sure, but probably most of the libraries 
doesn't have such symbol versioning in place.
Also, note that all packages must be linked to the 'default' version, 
unless strictly needed. And probably linking to libfoo1 and libfoo2 
simultaneously should be checked automatically (e.g. AutoQA) and 
forbidden completely.

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


More information about the devel mailing list