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

Hedayat Vatankhah hedayat.fwd at
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.


> -- Rex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list