1 |
On 30/03/2015 12:42, Holger Hoffstätte wrote: |
2 |
> On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: |
3 |
> |
4 |
>>> OK, then so why do I have to edit files to tell the system to USE this |
5 |
>>> and that after the system tells me it needs that ... ? |
6 |
>>> |
7 |
>>> Why isn't this taken care of within portage itself? |
8 |
>>> |
9 |
>>> I don't *want* to decide 32bit or not ... (I like that I *can* ...) |
10 |
>>> |
11 |
>>> I want a (mostly) stable and current linux system with the necessary |
12 |
>>> choices done by the maintainers ... if Skype needs it ... ok, then make |
13 |
>>> that a dependency/requirement somewhere ... but why force me to set that |
14 |
>>> (for so many packages) ? |
15 |
>> |
16 |
>> OK, think it through first. |
17 |
> |
18 |
> Sure thing. |
19 |
> |
20 |
>> You want skype. Skype is 32bit. So far, we're good. You put an entry in |
21 |
>> package.use to enable abi_x86_32 for skype. |
22 |
> |
23 |
> Except..at that point you would have already failed. |
24 |
|
25 |
That does not compute. Please explain. |
26 |
|
27 |
|
28 |
> |
29 |
> There is no good reason whatsoever why portage shouldn't be able to treat |
30 |
> this like a transitive required USE flag requirement, percolating through |
31 |
> all libs from the toplevel requirement's dependency tree. |
32 |
|
33 |
Correct, there is no good reason why portage *can't* do that. |
34 |
There is a very good reason why portage *won't* do that, it is not the |
35 |
gentoo way and it goes against gentoo's social contract. |
36 |
|
37 |
Portage does not override your choices, and it certainly does not allow |
38 |
one single ebuild to automagically change the behaviour of multiple |
39 |
other ebuilds. The correct way to bring about changes in behaviour is to |
40 |
add your global choices to make.conf (which is outside the control of |
41 |
the tree), or to add your explicit changes to package.* |
42 |
|
43 |
Portage's default behaviour when confronted with incompatible settings |
44 |
has always been to detect them, and print the output to the console |
45 |
telling you what to do. Now, there is a helper function that you as the |
46 |
system owner can enable if you trust portage and the tree to always make |
47 |
the correct decision - autounmask. You can run it with -p to get a full |
48 |
list that you can edit before running it for real, or you can just let |
49 |
portage go ahead and make the changes it feels are correct. But this is |
50 |
not default behaviour and for very good reason. |
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 |
I don't understand why you are advocating a dramatic change in portage's |
57 |
behaviour from what it has done for years. Yes, this latest feature does |
58 |
require some work from you. You have been doing this same work for ages, |
59 |
the main difference being that this time it's a large amount of once-off |
60 |
work. |
61 |
|
62 |
|
63 |
> |
64 |
> In fact it should do so automatically when the ebuild declares the abi_x86_32 |
65 |
> constraint from the start, without requiring the user to do anything. |
66 |
|
67 |
So you want a single ebuild to trigger a tree-wide change in behaviour? |
68 |
|
69 |
I don't think that's a good idea |
70 |
|
71 |
> |
72 |
> There are other reasons why coupling the native and 32-bit worlds together is |
73 |
> a bad idea in the long-term, regardless of understandable technical reasons |
74 |
> and good intentions. |
75 |
> |
76 |
> So yeah: think it through first. |
77 |
|
78 |
|
79 |
I already did. Refer this post. I think I thought about it in ways that |
80 |
you have not considered yet. |
81 |
|
82 |
|
83 |
-- |
84 |
Alan McKinnon |
85 |
alan.mckinnon@×××××.com |