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

[Martin Vaeth]

Kent Fredric <kentfredric@×××××.com> wrote:
>>
> 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?

Yes, this is the idea.

(Although I must admit that meanwhile I prefer the ebuild idea).

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

Exactly: Those which are part of the Perl built itself would not have a
useflag at all.  Only for those which are *not* in part of the current
perl built you would have a useflag. For instance,
USE=Time-Piece would not occur in the perl-5.10* ebuilds but in all
other perl ebuilds in the form
PDEPEND="Time-Piece? ( perl-core/Time-Piece )"

Packages needing Time-Piece would then just
RDEPEND="dev-lang/perl[Time-Piece(+)]"
and would thus implicitly get the correct dependency.

Once the translation is done, the only place where maintenance is needed
are the perl-ebuilds.

> But why would you "depend on the perl-provided version"

Many packages only need the basic functionality of a library,
not a particular version. The problem is that something like

RDEPEND="virtual/perl-..."

implicitly depends on a particular version, namely the highest
one which is currently stable/unstable for your architecture
instead of the one which avoids unnecessary installation.

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

If the user explicitly requires a particular package or
if a package explicitly depends on a certain minimal version,
the upgrade will be automatic.
However, if there is no need (dependency or explicit user request)
for a particular version, the installed version should be sufficient.

> You realise thats breaking how upstream thinks toolchains work right?

Upstream always thinks that you have to use the most current
unstable version of everything. This is not only true for perl
but also for every other bigger project (texlive or many others
come to mind).  It is the distribution's task to give a more
stable user experience.

> You're missing a very important point: Every single line of output without
> the uniq constraint is a package depending on a virtual.

This is not the case, but this need not be discussed here;
we agree that the number of *packages* depending on
virtual versions is large.

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

No. You just keep those few virtuals for which the packages explicitly
depend on the version. The remaining ones - for which the version
plays no role - are replaced *once* by the corresponding USE-dependency.

(However, as said above, I meanwhile prefer the eclass idea;
with the eclass you could treat both cases - those depending on
a particular version and those depending only on *some* version - in the
same way and even omit all virtuals.)

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

Both solutions would require only *once* to modify the dependencies.
After the transfer is done, you only have to modify 1 line

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

Only if there would be only *one* version of the corresponding
virtual. With *more* virtual versions as it is currently,
it is rather likely that an unneeded version of
perl-core/Term-ANSIColor is pulled it.

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

But if I am just installing virtual Y, version does not matter,
I will likely get virtual Y, versions X+Z although version X
is already there and thus version Z would not be needed.

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

This is a lazy excuse: Instead of producing proper dependencies
you are shifting the work to the user.
In fact, I did this work in the beginning, but not only is this a
lot of work for every perl upgrade (which is not so trivial to script),
you also need a lot of exceptions where the mask is not possible,
because some package needs a newer version.
For e.g. overlays which I provide to users, I do not want to
shift *my* work on the user's side and thus have to write clumsy
dependencies without virtual/...

If you use the ebuild or USE-idea you would get correct dependencies
which do not require the user to hack around and mask things only
to avoid unnecessary installations.

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

If you are writing an ebuild X whose action of src_install() depends
implicitly on the installed perl-version and the user executes
emerge --buildpkg=y X
on one machine and
emerge --usepkg X
on another machine (or at a later time) he will run into problems
without a warning if the perl versions of that two machines are not
the same (or have changed meanwhile) when the two commands are
executed.
Roughly speaking, you build an implicit dependency into the
*.tbz2 file which portage is not aware of and will not warn
the users about.