1 |
On Mon, 30 Mar 2015 13:14:55 +0200, Alan McKinnon wrote: |
2 |
|
3 |
> On 30/03/2015 12:42, Holger Hoffstätte wrote: |
4 |
>>> You want skype. Skype is 32bit. So far, we're good. You put an entry in |
5 |
>>> package.use to enable abi_x86_32 for skype. |
6 |
>> |
7 |
>> Except..at that point you would have already failed. |
8 |
> |
9 |
> That does not compute. Please explain. |
10 |
|
11 |
That was my somewhat categorical way of saying that you'd be repeating |
12 |
yourself with no benefit. The ebuild already knows that it's 32-bit only, |
13 |
so making e.g. the user declare the same thing again would be wrong to begin |
14 |
with. I realize of course that's not how it is done, and that the abi |
15 |
constraint is a required part of the ebuild for precisely that reason. |
16 |
|
17 |
That the current transitional situation is a bit messy - fine. |
18 |
|
19 |
>> There is no good reason whatsoever why portage shouldn't be able to treat |
20 |
>> this like a transitive required USE flag requirement, percolating through |
21 |
>> all libs from the toplevel requirement's dependency tree. |
22 |
> |
23 |
> Correct, there is no good reason why portage *can't* do that. |
24 |
> There is a very good reason why portage *won't* do that, it is not the |
25 |
> gentoo way and it goes against gentoo's social contract. |
26 |
|
27 |
That sounds great until you realize that selective capability configuration |
28 |
(aka USE flags, which I love and agree with!) is not the same as multilib |
29 |
profile selection. |
30 |
|
31 |
I really do understand the *idea* of strictly driving system capabilities |
32 |
from user-defined USE flags, so when you say: |
33 |
|
34 |
> Portage does not override your choices, and it certainly does not allow |
35 |
> one single ebuild to automagically change the behaviour of multiple |
36 |
> other ebuilds. The correct way to bring about changes in behaviour is to |
37 |
> add your global choices to make.conf (which is outside the control of |
38 |
> the tree), or to add your explicit changes to package.* |
39 |
|
40 |
..that just shows the root of the problem: the ABI is not handled |
41 |
consistently, but rather as a per-package configuration choice. |
42 |
|
43 |
I already *collectively opted into* the 32-bit parallel universe by |
44 |
*choosing multilib*. All the current way is doing is repeating that choice |
45 |
without accomplishing anything, esp. since I cannot reasonably NOT make that |
46 |
choice. It's a hard requirement if I want to run a certain application. |
47 |
|
48 |
It's great that Gentoo "gives me choice", but I hope you can see how |
49 |
not having a certain capability or not runnig an application at all are |
50 |
two very different shoes. |
51 |
|
52 |
> I get the sense that those who are complaining about abi_x86_32 in this |
53 |
> thread are mostly not complaining about what portage does, they are |
54 |
> complaining about the number of entries they have to make to portage.use |
55 |
|
56 |
No, they are complaining about the effects of the conflation of concepts, |
57 |
which ends up first in their config file (either manually or by portage), |
58 |
and eventually in their face, increasing the possibility of making completely |
59 |
unrelated mistakes later on. |
60 |
|
61 |
It also gives the false impression that this is a configuration choice, which |
62 |
it really isn't (see above). |
63 |
|
64 |
This also alludes to the secondary aspect I mentioned. Tightly coupling |
65 |
configuration choices possible in one world to the parallel world is going |
66 |
to be a real problem moving forward, precisely for the same reason: |
67 |
conflating a single mechanism for two different worlds with possibly |
68 |
different hard requirements. |
69 |
|
70 |
>> In fact it should do so automatically when the ebuild declares the abi_x86_32 |
71 |
>> constraint from the start, without requiring the user to do anything. |
72 |
> |
73 |
> So you want a single ebuild to trigger a tree-wide change in behaviour? |
74 |
|
75 |
Yes, *because I chose multilib*. That is *exactly* what I want, and - judging |
76 |
by some of the posts here and in the forums - also what most people seem to |
77 |
expect. |
78 |
|
79 |
I'm starting to wonder if it wouldn't be much more economical to provide |
80 |
prebuilt stacked layers of Docker images for 32-bit compatibility. |
81 |
That would solve several classes of problems at once, and not pollute the |
82 |
native Gentoo way with ultimately unsolvable problems. |
83 |
|
84 |
-h |