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

[Hedayat Vatankhah]

/*Kevin Fenzi*/ wrote on Fri, 13 Feb 2015 11:36:47 -0700:
> On Fri, 13 Feb 2015 15:21:17 +0330
> Hedayat Vatankhah <hedayat.fwd at gmail.com> wrote:
>
> <...>
> 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.
I'm not sure if things will be (much) worse than the current situation. 
Maintainers already do maintain multiple versions of the same library, 
and also the upgrade path from a Fedora release to the next should work. 
My assumption was that the effort needed to properly package libfoo3 for 
F21, is not more than what is already needed when you package it for 
Rawhide/F22.

> 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.
Certainly. 3 was a typical example. Having less versions is certainly 
OK. A maintainer can provide more than 3 versions if he wish, but he 
might stick to 3 versions. e.g. If he expects the library to change 
versions too early, he might skip some versions: package libfoo2 and 
wait for libfoo4. Also, he might have libfoo2 and libfoo3. When libfoo4 
released, he can add it and stop maintaining libfoo3 (no further updates 
for libfoo3) but actively maintain the default version (libfoo2) and the 
latest version (libfoo4). He might even jump to libfoo5 if it is 
available. For the next release, it could have libfoo2 (the 'default' 
version of the previous release) as compatibility package and libfoo5 as 
the 'default' version.


>
>> 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.
I don't suggest providing the 'default' version as "Provides:" for the 
default package. Instead, I suggest having a separate package as 
'libfoo' which depends on the 'default' version. The package is very 
unlikely to change during a Fedora release life cycle, so you rarely 
merge any changes to it (libfoo depends on libfoo2 in F21, and nothing 
else). I can't imagine any kind of updates for such a package right now.


> ...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.
How do we do it exactly? More specifically, what do we do about the 
'default' version? The one a typical './configure' should be able to 
find? Things like these should keep working: looking up the header file 
of the library (e.g. /usr/include/pcap.h), running the expected config 
executable (e.g. pcap-config), using pkg-config to find the desired 
library (pkg-config --libs python, which already works), etc.

Actually, I think we are talking about the same kind of solution. I 
mentioned alternatives system, but I didn't necessarily mean being able 
to change the default version by users (while that can be nice also). 
So, doing something like what python-devel/python3-devel does right now 
is OK. The default symlinks can be provided by the default (libfoo) package.


>> 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?
Yes, I think so. (It also means some changes in other places, like some 
release engineering changes to create git repositories). I also suggest 
it to be the default/encouraged packaging schema.

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