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

[Martin Vaeth]

Sorry if this is duplicate: I repost since I cannot see it after
a few hours.

Kent Fredric <kentfredric@×××××.com> wrote:
>
> On 27 September 2013 08:02, Martin Vaeth
><vaeth@××××××××××××××××××××××××.de>wrote:
>
>> For those which are provided by perl itself, you could have
>> a corresponding useflag of dev-lang/perl and make a use dependency:
>> If the main perl tarball does not provide the package, the perl ebuild
>> can pull in the corresponding package as a dependency.
>
> That would be horrible. You'd have a massive list of USE flags, and you'd
> want *all* of them by default, and they'd have to pull the deps as
> PDEPENDS, because its impossible to have them as DEPENDS.

Why is this horrible?  Perhaps there is a misunderstanding.
You would need only those useflags which are possibly not provided
by the corresponding perl version: The package dependent on a feature
could just use e.g. DEPEND=dev-lang/perl[perl_module_Term_ANSIColor(+)]
And concerning the number of use-flags, it might be worth thinking
about a USE_EXPAND="perl_module".

> so maybe rebuild the entirety of Perl, just to install one thing that
> can be installed seperately from Perl.

If the common flags are enabled by default, this would only involve
users who have a serious reason (e.g. space issues) to disable some
modules.  Yes, these users would have to rebuild unnecessarily if
they change their mind later on.  I would compare disabling these
modules with something like setting USE=minimal for other packages;
users should know what they are doing if they use this.

> Also, instead of having the logical thing when Module::Build does get fully
> removed from perl, that we can simply remap the virtual to always pull from
> perl-core/Module-Build, we'd have to re-write every package in tree that
> used Module-Build.

My idea is to keep this in the perl ebuilds "forever":
According to the perlversions which are still in the tree, it will take
dozens of years until all perl versions providing Module-Build have vanished
from the  tree, and only afterwards it makes sense to think about
such a change.

> This is a problem with Module::Build, Test-Simple
> and ExtUtils::MakeMaker, because people regularly depend on specific
> versions of those things

My suggestion was explicitly about modules for which ebuilds do
not require an explicit version. For those few(!) modules for which
particular versions are needed, perhaps the virtual might be kept.
Alternatively, for such cases it might make sense to depend
directly on the package, since the probability to save duplicate
installation in such a case is rather low, anyway.

> Worse than that I'm afraid, things that are virtualled are virtualled
> because upstream can and will depend on a specific version of that thing

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

And I guess that in this list of (for the main tree, but even with
eix -Z ... the list is hardly longer) 62 packages
actually many fall into the class where the minimal version is
provided by current stable perl version anyway so that actually the
minimal version dependency is redundant.

> And more, there is the growing list of modules that may be presently
> installed with perl, but are slated to stop being shipped with perl
> [...] and inlining a big list of
> conditional dependencies in each and every module that uses such a package.

I was not suggesting inlining the list into the dependency but
only inlining the USE-flag into the (single) perl ebuild.
Currently if I have a package which needs e.g. Term-ANSI-Color,
but not in a particular version, if I do not want to install an
unnecessary duplicate version, I must inline a dependency like
|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor )
and possibly change this if perl-5.20 does no longer contain
perl-Term-ANSIColor.