-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 05/08/13 01:07 PM, Rich Freeman wrote:
> On Mon, Aug 5, 2013 at 12:15 PM, Alexis Ballier
> <aball...@gentoo.org> wrote:
>> On Mon, 5 Aug 2013 18:10:46 +0200 Michał Górny
>> <mgo...@gentoo.org> wrote:
>>> We can simply have multiple virtual versions, each depending on
>>> the proper jpeg & jpeg-turbo versions.
>>
>> you can do it that way, yes.
>>
>> what will you do when jpeg 10 is out or when libjpeg-turbo
>> changes its abi ? wait for each provider to have a release that
>> changes the abi ? this doesnt sound sane
>
> I think a thorough solution needs to handle the passthrough
> situation, and ideally the multiple libs per package situation.
>
> Our whole versioning system wasn't really set up with this stuff
> in mind either. We're dealing with ABI/SONAME versions here - not
> functionality versions. A package with jpeg-turbo SONAME 0.6 might
> be a superset of all the functionality in SONAME 0.9 - the larger
> number doesn't mean better, just different.
>
> It might still be possible to handle this with subslots as they
> are currently implemented, but I'd have to really mess around with
> it to be sure. The logic of higher-number = more-desirable is
> likely to cause problems - you don't want your system to force you
> to move from jpeg-turbo to jpeg because only the latter is a dep of
> a newer virtual.
This is the primary reason as to why sub-slots were designed as they
were, to be an independently set value -- it allows the maintainer of
say, jpeg-turbo to bump the subslot value only when necessary (for
instance, in the case of SONAME 0.6 being a complete superset of 0.9,
there is no need to bump sub-slot as long as it is known that all
consumers are only consuming the subset of functions available in 0.9
(and if they aren't, I expect there's going to be compile-time
breakage anyhow).
This is starting to go off-topic, but it's one of the reasons I don't
like seeing packages with SLOT="0/${PV}" or similar -- to me, a
sub-slot bump should really be evaluated on its own merits and not
just for any version bump.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iF4EAREIAAYFAlIBBZwACgkQ2ugaI38ACPCuuAD9HhPrGA5A7BN4FM8X58la/r0+
wpzueqNlPFAk9WCZkScA/0gfqkYP9GuAFBtQPq8zbEiEqX8DDRZ03FQYISSlrv8B
=bSZH
-----END PGP SIGNATURE-----
