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

Hedayat Vatankhah <hedayat.fwd@xxxxxxxxx> · Sat, 14 Feb 2015 00:12:44 +0330

      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@xxxxxxxxx> 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

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