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

[Martin Vaeth]

Kent Fredric <kentfredric@×××××.com> wrote:
>
> you'll still need logic like "|| (
> dev-lang/perl[perl_module_Term_ANSIColor(-)]   perl-core/Term-ANSIColor )"
> to just deal with the reality of what upstream are asking for.

My point is that the perl ebuild need not necessarily follow upstream:
It follows what the perl *ebuild* provides.
If upstream decides to remove a package, you can just pull it
from the ebuild (with PDEPEND, I agree) nevertheless.

> If such a list of USE flags existed, it would be a very strong
> recommendation that they *ALL* be turned on.

Yes, this is why I said manually disabling is comparable with
setting USE=minimal: for most users not recommended unless you
really have the necessity to build a minimal system for some reason.
So I would not care too much about occassional unnecessary recompilation
of perl itself only for the small numbers of users having such a necessity.

> And pulling in perl-core/Whatever by doing
>=dev-lang/perl[perl_module_whatever] is just a nastier form of
> virtual/perl-Whatever, with the limitation that you're completely
> destroying any version support.

If you need version support you still can depend on perl-core or virtual/*
but currently there is no way to explicitly prefer the perl-provided version
in the dependency (unless you code it manually).

> Thats not really the issue, the issue is that because the modules *ARE *deemed
> dual life by upstream, that is, it is expected that end users can depend on
> a specific version of a module that exists in both perl itself, and as a
> standalone, that end users *may* depend on such things and expect that to
> work.

Yes, he may depend on the explicit perl-core/* with version
(and perhaps also some virtual/* where it is likely that such
an explicit version is provided by perl itself - probably only
very few):

>> As mentioned above, this involves only a relatively small number of
>> virtuals. Here is how I got the list:
>>
>> eix --print-all-depends |  sed 's/"//g' \
>>   grep -o '[^ ]*virtual/perl-[^ ]*-[0-9][^ ]*' |sort -u
>>
> I get 566 for me.

different *minimal versions* but much less (IIRC 62) packages
which is already now lower than the number of virtual/perl-*.
Moreover, many of the minimal versions are probably meanwhile
redundant (since the highest version is stable anyway and often
already provided by current stable perl).
Since most packages occur only once or twice, I guess that if the
redundancy is eliminated you end up with only 10-20 for which a
virtual might really make sense (or, alternatively, for which you
must directly depend on perl-core/*, since the probability to
just have the correct version in perl is rather low anyway).

> And note, you're showing the dependencies, not the dependants.

This is the point, because only this is what is interesting:
You do not need a virtual with version number if absolutely nothing
is using it.

> If you remove the unique criteria, you get a lovely 20260 lines
> of output!

This number has no meaning. Moreover, if you should decide
to change the way how modules depend, this is a question
of writing a single perl-script ;)  which changes the style
in all ebuilds. I can gladly provide such a script if you want.

>|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor )
>
> That is plain wrong imo. You're prematurely optimising the dependency.

The alternative is to pull in a duplicated installation which is
completely superfluous, since it is already installed by most
perl versions,

> There is no guarantee any future version of Perl will contain it.

That's why it is necessary to manually update the dependency -
a lot more work than to depend on dev-lang/perl[Term-ANSIColor]
and only edit a future perl ebuild to pull in the package.

> The virtuals job is to invoke dependency on dev-lang/perl as much as
> possible, and default to perl-core/* when dev-lang/perl does not provide
> the version matched on the virtual.

In this example (one of many) the version plays no role
for the dependency, but nevertheless the virtual/... implementation
will pull in an unnecessary package.

> I'd also sooner consider attempting to eliminate the need for virtuals by
> unilaterally depending on perl-core/* , and vivifying perl-core/ from
> dev-lang/perl sources as needed.

This breaks proper support for building/using binary packages for
perl-core/* since the installed files will depend on which packages
are installed at build-time.