Proposal to (formally/easily) allowing multiple versions of the same library installable
Hedayat Vatankhah
hedayat.fwd at gmail.com
Fri Feb 13 18:16:29 UTC 2015
/*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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/232792be/attachment.html>
More information about the devel
mailing list