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

[Martin Vaeth]

Kent Fredric <kentfredric@×××××.com> wrote:
>>
>> 1. The virtual does not even exist :)
>>
>
> Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0

In this case the virtual is buggy, becaues it does not contain
|| ( dev-lang/perl-5.18* ... )

Due to this, this particular example is not so ideal: I wanted to
have an example where the stable virtual/perl-... version is higher
than the one provided by (stable) perl. (This is then not the case
once the virtual got fixed and perl-5.18 gets stable.)
Please replace this example by one for which this is the case, say

virtual/perl-Digest-MD5

and assume that I want an ebuild for a package for which *any* version
of perl-Digest-MD5 would be sufficient.
In this (now hopefully correct) example, if I do not write
something like

RDEPEND="|| ( >=dev-lang/perl-5.12 virtual/perl-Digest-MD5 )"

or

RDEPEND="|| ( =dev-lang/perl-5.12* ... virtual/perl-Digest-MD5 )"

but instead only the "natural"

RDEPEND="virtual/perl-Digest-MD5"

I would currently pull in unnecessarily perl-core/Digest-MD5-2.520.0
or perl-core/Digest-MD5-2.530.0 (depending on whether the user
is using e.g. ~amd64 or amd64).

What I meant was that one might have the strange idea to use
as a "workaround" for this problem the dependency

RDEPEND="=virtual/perl-Digest-MD5-2.510.0-r2"

but this would be a very bad idea many reasons, in particular:

>> 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

This is what I mean by "ebuilds depending on other versions".
The above "workaround" would unnecessarily block ebuilds which
contain

RDEPEND="... >=virtual/perl-Digest-MD5-2.520.0 "

> This is seen as a "feature"

I agree. I just wanted to point out why the "workaround" is not
really a workaround of the problem but would be just a very
bad idea.

>> 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 [...] you'll
> need to change your dependency string in your package

Exactly: This is what you would have to do, and which is not solved
by the current virtual/... approach unless you accept pulling
in unneeded dependencies.

> Virtuals are much more convenient here

More convient than putting into the ebuild, but at the cost
not only of maintaining the virtuals but also of installing
duplicate packages on the user's system.
Take the above (hopefully correct) example that you
have the "natural"

RDEPEND="virtual/perl-Digest-MD5"

Although *any* perl version containing this module would be
sufficient, this dependency will install for a user with
unstable keywords in addition perl-core/Digest-MD5-2.330.0,
because this is the currently highest available version of
the virtual and not satisfied by any perl version.
(Similarly for the user with stable keywords, it will
install currently unnecessarily perl-core/Digest-MD5-2.320.0
and when perl-5.18 hits the stable tree, it is rather likely
that also >=virtual/Digest-MD5-2.330.0 is stable so that the
user has unnecessary duplicate versions installed throughout.)

> (Actually, thats a bug still, because corelist -a says 4.20.0 should be
> available in 5.18

In my local overlay, I have a list of ~30 more such virtual/perl-*
for which I have fixed dependencies (though maybe I have falsely
translated the version numbers). This does not belong to this
mailinglist, so if I you are interested in the virtual list or if
I should open a bug, drop me a pm.

Both suggested solutions (eclass or dev-lang/perl-... with useflags)
would avoid all of these problem:

You have to update only one list of packages for every perl version,
not update every single virtual/... and, more important, the
dependencies would not pull in unnecessary packages for the user.