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

[Kent Fredric]

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.

And that would mean: X package wants Module::Build, so not only do you have
to declare a dependency on Module::Build somehow, thats controlled by a USE
flag, so maybe rebuild the entirety of Perl, just to install one thing that
can be installed seperately from Perl.

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.

I was asking for solutions that reduce work, not increase it =p

And when you wanted a specific version of a "dual life" module, you'd be
completely out of luck. ( This is a problem with Module::Build, Test-Simple
and ExtUtils::MakeMaker, because people regularly depend on specific
versions of those things )


> This is appropriate if
> something really needs a newer version, but not just because something
> *must* depend on the virtual only because some perl versions do
> not provide it.

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,
and time to time, those versions are available only via CPAN, not via the
present version of Perl

And other times, upstream will depend on an explicit version which is
available only in specific versions of perl, and virtuals are the only tool
we have at present to mitigate these problems.

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 in a
future release of perl. That means things that don't depend on the virtuals
*now* will be broken when that version of perl ships, and its much, much
easier to use the virtuals to resolve this problem, as opposed to tracking
down all the modules that need to be fixed, and inlining a big list of
conditional dependencies in each and every module that uses such a package.


-- 
Kent