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

Hedayat Vatankhah <hedayat.fwd@xxxxxxxxx> · Fri, 13 Feb 2015 21:46:29 +0330

      Rex Dieter wrote on Fri, 13 Feb 2015 11:15:58
      -0600:

      Hedayat Vatankhah wrote:

        2. No reviews are required for new libfooX packages (as it is not
required right now when you update your libfoo package

      I disagree with this point, reviews are important, arguably *more* important 
in special cases like parallel-installable libraries.

    That will make it a no-go. Currently, no packages are being
    re-reviewed on updates, and I consider creating libfoo3 a kind of
    update too. My intention is to make it a normal case rather than a
    special case. If consistency tests or similar are needed, there
    should be tools to do it. But I think the .spec doesn't need a
    re-review since it should be essentially the same .spec used for
    libfoo2. This really is not a "new" package.  However, if some
    special kind of review is required in this case (rather than a full
    review), specially if it can be a (maybe automatic) 'self review',
    it might work. 

        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.

      +1 for option 2, option 1 is bad, there be dragons.

    Hmmm... I don't understand how option 1 can be worse than the
    current situation. BTW, I personally would prefer all libraries to
    provide option 2, but it would work fine if it is supported by the
    distribution (so that maintainers should not do it their own way).
    But if it proves to be hard to get it right, I think option 1 would
    serve most use cases very well. 

    Again, the main reason for this proposal is to serve 'users' (end
    users/developers) by providing compat & latest versions; not to
    serve the distro itself. Fedora packages should keep using the
    default version in almost all situations.

Though there are many opportunities for bikeshedding, the rest of your 
proposal seems reasonable.

    Thanks

    Regards,

    Hedayat

-- Rex

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