On 28 September 2013 22:31, Martin Vaeth <va...@mathematik.uni-wuerzburg.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
