Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Kent Fredric]

On Mon, 10 Apr 2017 11:52:02 -0400
"William L. Thomson Jr." <wlt-ml@××××××.com> wrote:

> >
> > Meanwhile, you cannot build two parts of a given python dependency
> > chain with different pythons, nor different perls.
>
> True but this is not changing how things work, just reversing.

You mean going back to the old days where you'd upgrade Perl, and your system
would simply be broken, and you'd need to run some 3rd party tool outside of portage
to fix it, otherwise all your compiles would randomly break because portage had no
way of knowing that everything Perl based was now broken?

Or where we had python-updater for the same reasons?

TARGETS is a *solution* to these kinds of problems. Don't dismiss the solution
simply because you don't understand the problem in the first place.

Its not *ideal*, but its far better than things were.

We actually *do* have many users now having effortless upgrades as a result
of both targets and subslot usage, which you'd have us repeal.

1. Install new perl, subslots change, portage reinstalls everything
  ( portage currently does a shit job though of getting this right in all cases, 
    but enough users have it JustWork and perl-cleaner is only necessary because they had
    ages of old stuff that wasn't installed with subslot binding )
2. Globally change PYTHON_TARGETS, all things needed to be rebuilt with python get rebuilt.

"Lets not rebuild" is _not an option_. Not rebuilding is simply opting to
have a broken system.

You need to present a strategy for causing the rebuild, and presenting
a rebuild that doesn't result in end users having a fractal of brokenness.

And a "Supports everything by default, but then we mask things off as broken"
creates a "broken by default" system.

>
> > Right, but this is impossible with Ruby, Python, and Perl.
>
> It is done right now.  The problem your describing exist now and is
> addressed. This would address it the same way but reversed.

Its *not* addressed now. For instance, if you recompile Perl with USE=threads
or USE=debug, you have to recompile literally every package you have installed.

We have no solution for this in place, and we have tempted the idea of a TARGETS
analogue for a few years now.

The only reason it *kinda* works now is because Perl's upstream takes massive efforts
to ensure that when they break things, the people whos shit got broken is fore-warned
of the impending doom, with aggressive smoke testing on the pre-releases.

Subsequently, the fact we don't already have Perl with TARGETS is simply because the breakage
is typically fixed upstream *before* it hits us.

If shit is broken sufficient that it won't work on a newer Perl, that's a tree breakge for us.

And its soley by the grace of God that such a thing has not been significant enough to cause a blocker yet.

Python and Ruby don't have any sort of culture to make this possible. 

> > Perl *could* have targets, and some people think could do with it,
> > but it and java are very much in different boats.
>
> Easier to deal with as a user. Less work as a developer.

Which kind of user? The user who lives on the bleeding edge and doesn't mind randomly having
emerge break?

What about the audience of users who bitch every time we stabilize a new version of Perl, because
they're not ready for the changes?

Its a good thing nobody users Gentoo in production, because we move far too fast
for anyone to rely on our operating system for anything serious.

There's plenty of codebases out there that still require older versions of Perl, and
if the *massive* catastrophe of 5.26 doesn't abate, no doubt we'll need a way
to concurrently install multiple Perl versions to support a legacy audience.

And as soon as we have concurrent Perl versions available, a TARGETS analogue becomes a
*necessity*, portage has no alternative.

How else does portage understand the following facts:

   X package exists
   X package has 3 dependencies
   X package needs Perl 5.26
   X therefor needs all 3 dependencies to be installed on Perl 5.26

That is, you can either slot *every* package in tree for *every* perl there is and create
a *massive* maintainer burden ( read that as: I quit ), or you introduce targets, so that
portage can track the interconnectedness of packages and what they're installed on.

There's literally no other mechanism to do this at present.

Python used to have an ENV hack that was *like* targets, except portage couldn't see it,
and was basically just broken by design.

Thus, going back to the old way is "still have targets, just you're fucked if you expect portage to help you with
them and you'll need 3rd party tools and a daily battle with portage not understanding why its dependencies
are broken"
 
> Problem is simple, Targets are a PITA to deal with, ever changing. They
> lead to issues when you select incompatible ones or options. Best case
> wild card and let all install. But otherwise its a chore to deal with.
>
> > We only have 2 types of option at present from the users perspective,
> > "on" options, and "off" options.
>
> That sounds terrible. Lots of distros with things already turned
> on/off. Gentoo should never be one. USE flags can be a PITA, but they
> are a necessary evil. Its the ever changing TARGETS that are annoying,
> and cumbersome to users.

Read the rest of my comment. I said this is what we *currently* have.

It *IS* terrible. That's why I proposed an alternative.

We *currently* have a system of binary toggles, and our system basically forces users
to decide upon things, even if they don't care. And when packages conflict with things that
users don't care about, it forces them to care to flip the bit. ( And then later something
else forces them to unflip it, ad-infinitum )

End users don't care if mercurial needs 40 dependencies to have python 2.7 support enabled.

They just want to install mercurial and have portage do the leg work to make it happen.

Hence, the default should not be "Python 2.7 all the things!"... but it shouldn't be "fuck python2.7!" either.

The default should be "Portage can turn on Python2.7 support when its deemed necessary due to dependency chains,
but otherwise leave it off", and if users are sticklers about it, THEN they can set a hard line of "python 2.7 all the things"
or "no python2.7"

We currently have the worst of both worlds.

But please, actually understand the problem before attempting to tell us you don't like the solutions.