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

[Kevin Fenzi]

On Fri, 13 Feb 2015 15:21:17 +0330
Hedayat Vatankhah <hedayat.fwd at gmail.com> wrote:

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

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

But the thing is, it's really difficult to get right details about the
new package. Forget to change a name somewhere or a provides or
obsoletes. People mess this up all the time. 

Also, this would vary library to library. Some things change slowly and
only support 1 release, some things (cough *ffmpeg*) change version
every release. So in some cases 3 is too many, and in others not
enough. 

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

So, you would need t move these 'default' provides to different
versions on different branches? Doable, but again, someone could merge
back a change and mess up this, so it sounds pretty delicate.

...snip...

> 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

Bad idea. Conflicts are horrible and to be avoided. 

> 2. Flexible: Provide the possibility of installing multiple -devel 
> versions, and a method to select the "default" one, like the 
> alternatives system.

More complexity... but also there is: 

3. What we do today: make sure all versions are parallel installable. 
 
> 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.

So, the gist of the proposal is to avoid reviewing new compat packages? 

Is this really such a burden? 

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

kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/18ea2435/attachment-0001.sig>