Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

[Kent Fredric]

On 28 September 2013 22:31, Martin Vaeth
<vaeth@××××××××××××××××××××××××.de>wrote:

>
> Note that it would be stupid to depend on e.g.
> =virtual/perl-Term-ANSIColor-4.02
> for several reason:
>
> 1. The virtual does not even exist :)
>

Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 ,
because upstreams versioning semantics are grossly different to gentoos, so
we translate upstreams floating point versions to multipart versions so
that version cross-dependency semantics stay the same.


> 2. It would collide with ebuilds depending on other versions.
>

Nope, it would only collide in the case other ebuilds depended on a
specific version, or blocked a specific version.

This is seen as a "feature", because of "foo" needs "<= y-nnn" you don't
want to have to logically tract that fact in every other package that needs
"y"


> 3. This version is only reasonable if perl-5.16 is the
> perl version which the user has installed


And when perl 5.18 hits tree, if you want exactly 4.20 or larger, you'll
need to change your dependency string in your package to incorporate this
fact, instead of saying ">=virtual/perl-Term-ANSIColor-4.20.0" you'll have
to do "|| ( perl-5.18 etc etc )" , which is pushing the dependency
management of all the virtuals into the pacakges that are requring them.

Virtuals are much more convenient here, because if we need to change the
provider of a single version, we change it in *one* place, instead of
having to modify every ebuild in tree that needed it.

( Actually, thats a bug still, because corelist -a says 4.20.0 should be
available in 5.18, but the virtual for 4.20.0 doesn't yet have perl-5.18
listed as a provider, though I'm glad it can be fixed once, there, instead
of having to fix it in every package that depended on 4.20.0 prior to the
arrival of 5.18 in tree )



-- 
Kent