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
