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

[Kent Fredric]

On 28 September 2013 07:48, Martin Vaeth
<vaeth@××××××××××××××××××××××××.de>wrote:

> 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".
>
>
Its just a "Perl module" here can be only "1 file",  and worse, you'll have
to mentally make sure the USE flags have the right interdependencies for
USE flags that require other USE flags to work.

And rebuilding all of perl to change the presence of one file, gives us a
lot of cost, and no benefit. And it still has the problem if a user wants a
version of something that we don't know where its going to come from for
all time, ie: 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.

This solution is presently worse than virtuals, because it requires every
ebuild to be aware of the mess of how resolving "dual life" dependencies
work.

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

The problem there is you're breaking upstream, because you're breaking how
upstream perceives perl to work.

If such a list of USE flags existed, it would be a very strong
recommendation that they *ALL* be turned on.  And again, this essentially
says "modules that are dual lifed are pretended not to be so", unless you
combine this approach with PDEPEND

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.

> 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


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.

In the event new modules do hit tree need something that is dual lifed, it
is much less effort to add a virtual to the tree to communicate the
dependency properly, much less effort than rehashing dev-lang/perl itself,
adding a new USE flag, and causing a domino of recompiles to deploy a
hand-full of files that may not even need compiling to work.


> > 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
>
>
I get 566 for me. Thats a bit longer =)  . And note, you're showing the
dependencies, not the dependants.

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

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.
>
>
>
|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor )

That is plain wrong imo. You're prematurely optimising the dependency.
There is no guarantee any future version of Perl will contain it. That is
*why* we have the virtual.

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.

This may not be important for *your* dist, but it is very necessary for
other things. Especially in the case of blocking versions.

I mean, the reason virtuals suck is predominantly the fact we have to
update the conditionals to accurately reflect the version on the virtual,
so that virtuals pull in perl-core/* if the version in dev-lang/perl
doesn't match the version.

Literally, the logical replacement for that is inlining that conditional in
every .ebuild that needs it.

We could, at very best, step around the problem by having an eclass that
translates a special variable, say,
PERL_MODULE_COREDEPS="Term::ANSIColor@3.2"  or something, and that then
translates those dependencies into the relevant switches. And that is
something I really want to avoid, mostly, because the massive amount of
moving parts required to implement such a feature.

I'd sooner opt for a way to represent the ebuild as a template, and then
have a process that generates ebuilds from the ebuild templates,
automatically -r bumping things as it found dependency changes.

At least that way, I wouldn't be limited to nasty arcane bash tricks that
could explode on a user  with relative ease.

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. Just the maint overhead for that is
slightly high, and entirely unsupported by upstream.




-- 
Kent