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

[Kent Fredric]

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

> 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.
>
>
So are you basically suggesting that for dual life modules, we simply
ignore that they're dual-lifeable, and then when upstream splits a package
from core so that its no longer dual life, that we simply ignore that too,
and fake it still being core for the forseeable future?


> 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.
>
>
IMO, really, the uses would be forced enabled for all users, because they
should never be disabled. If they're part of the Perl built itself, they
should get installed. Period.

Then by forcing them on all the time, you can use them how you were
initially suggesting, as a way to track interdependencies between versions
of perl ( ie: When perl itself stops being able to provide something, the
USE flag goes away ... but thats messy as hell, and an abuse of the entire
purpose of USE flags, to control features, not to simply track properties
of a package for the purpose of cross dependencies )

For that, a slot-dict approach is far more sane.


> > 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).
>
>
But why would you "depend on the perl-provided version" , that mentality is
nowhere upstream, and nowhere downstream.

Are you saying that, if something is provided by perl core, that we must
never update to a cpan version?

You realise thats breaking how upstream thinks toolchains work right?

Because even CPAN and friends like that will upgrade things in core to
their cpan versions where possible.

There is *no* way for upstream to declare "I want whatever version of X is
in your current perl", they can only state "I want X" or fail to state they
want X, and assume toolchain does the right thing.  Even then, that will
result in tools using more recent versions of things from CPAN.

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

But that raises a problem, because some versions that end users may depend
on are *NOT* available as perl-core/* , they are only available in a
specific incarnation of Perl.

Or sometimes, a version will appear on CPAN, and people will start
depending on it ( requiring you to invoke a perl-core/* dependency ), and
later, that version will be shipped in perl itself, resulting in the need
to retroactively modify every ebuild that depended on perl-core/* of those
versions to use the perl one instead.

Because otherwise, you'll have end users complaining they have to install
perl-core/Term-ANSIColor-4.20.0 when they're using 5.18.0, which comes with
that version 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.
>
>
You're missing a very important point: Every single line of output without
the uniq constraint is a package depending on a virtual.

The virtual is managing the need to have a conditional dependency based on
the version of perl installed.

You would need to ,without virtuals, modify *EVERY* ebuild containg a
dependency on a virtual, to contain the respective conditional dependency
enshrined in the virtual.

Not only that, instead of what we currently do, modify the indivual
virtuals to adapt to new perl releases, with the conditional codified in
the .ebuild, you would need to modify *EVERY* ebuild that had such a
dependency after *EVERY* perl release.

Not sure about you, but the idea of modifying 20,000 lines of code instead
of 1, is something I don't look on fondly.

>|| ( >=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,
>

You're not though. Thats the point. Virtuals are doing exactly that.
They're just doing it in the virtual instead of your ebuild.

If you are installing virtual Y version X, if you are on a version of Perl
that contains Y version X, the virtual avoids the need to install the
respective perl-core/X.

Thats exactly how they work, and is exactly their point.

If you want proof of this:

eix --only-names -IcC virtual | grep 'virtual/perl-'  | wc -l
50

 eix --only-names -IcC perl-core | wc -l
35

So thats 15 virtuals that are still not pulling in any superflous
perl-core/*

They don't need to, they've short-circuited to using perl instead.

If you don't like that packages get updated, and pull newer-that-core
versions of things, there's nothing to stop you grepping virtual/perl-*,
and masking versions that don't match an "=your current version of perl".

And then it will cease to pull in *any* perl-core/*

Lots of things will not work if you do that, but you can do that.

Sure, the perl-core/ family will be around for a little longer, but they
should become candidates for depcleaning as soon as the conditionals
default to perl.

You could also mask perl-core/* and see what that does, though I'd wager
you'll see a lot of things breaking.

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.
>
>
As stated above, if your objection is simply getting new versions of things
in core needlessly, be my guest, disable that mechanic. You can do so right
now. Though I'd advise against it, because that mechanic is nessecary for
many things, hence, why we have it.

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


I'm not really sure what you're sayng here. Sorry :/


-- 
Kent