[gentoo-user] Re: This nite's switch to "full multilib"

["Holger Hoffstätte" <holger.hoffstaette@googlemail.com>]

On Mon, 30 Mar 2015 13:14:55 +0200, Alan McKinnon wrote:

> On 30/03/2015 12:42, Holger Hoffstätte wrote:
>>> You want skype. Skype is 32bit. So far, we're good. You put an entry in
>>> package.use to enable abi_x86_32 for skype.
>> 
>> Except..at that point you would have already failed.
> 
> That does not compute. Please explain.

That was my somewhat categorical way of saying that you'd be repeating
yourself with no benefit. The ebuild already knows that it's 32-bit only,
so making e.g. the user declare the same thing again would be wrong to begin
with. I realize of course that's not how it is done, and that the abi
constraint is a required part of the ebuild for precisely that reason.

That the current transitional situation is a bit messy - fine.

>> There is no good reason whatsoever why portage shouldn't be able to treat
>> this like a transitive required USE flag requirement, percolating through
>> all libs from the toplevel requirement's dependency tree.
> 
> Correct, there is no good reason why portage *can't* do that.
> There is a very good reason why portage *won't* do that, it is not the
> gentoo way and it goes against gentoo's social contract.

That sounds great until you realize that selective capability configuration
(aka USE flags, which I love and agree with!) is not the same as multilib
profile selection.

I really do understand the *idea* of strictly driving system capabilities
from user-defined USE flags, so when you say:

> Portage does not override your choices, and it certainly does not allow
> one single ebuild to automagically change the behaviour of multiple
> other ebuilds. The correct way to bring about changes in behaviour is to
> add your global choices to make.conf (which is outside the control of
> the tree), or to add your explicit changes to package.*

..that just shows the root of the problem: the ABI is not handled
consistently, but rather as a per-package configuration choice.

I already *collectively opted into* the 32-bit parallel universe by
*choosing multilib*. All the current way is doing is repeating that choice
without accomplishing anything, esp. since I cannot reasonably NOT make that
choice. It's a hard requirement if I want to run a certain application.

It's great that Gentoo "gives me choice", but I hope you can see how
not having a certain capability or not runnig an application at all are
two very different shoes.

> I get the sense that those who are complaining about abi_x86_32 in this
> thread are mostly not complaining about what portage does, they are
> complaining about the number of entries they have to make to portage.use

No, they are complaining about the effects of the conflation of concepts,
which ends up first in their config file (either manually or by portage),
and eventually in their face, increasing the possibility of making completely
unrelated mistakes later on.

It also gives the false impression that this is a configuration choice, which
it really isn't (see above).

This also alludes to the secondary aspect I mentioned. Tightly coupling
configuration choices possible in one world to the parallel world is going
to be a real problem moving forward, precisely for the same reason:
conflating a single mechanism for two different worlds with possibly
different hard requirements.

>> In fact it should do so automatically when the ebuild declares the abi_x86_32
>> constraint from the start, without requiring the user to do anything.
> 
> So you want a single ebuild to trigger a tree-wide change in behaviour?

Yes, *because I chose multilib*. That is *exactly* what I want, and - judging
by some of the posts here and in the forums - also what most people seem to
expect.

I'm starting to wonder if it wouldn't be much more economical to provide
prebuilt stacked layers of Docker images for 32-bit compatibility.
That would solve several classes of problems at once, and not pollute the
native Gentoo way with ultimately unsolvable problems.

-h