1 |
On Mon, 30 Mar 2015 13:14:55 +0200 |
2 |
Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
3 |
|
4 |
> On 30/03/2015 12:42, Holger Hoffstätte wrote: |
5 |
> > On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: |
6 |
> > |
7 |
> >>> OK, then so why do I have to edit files to tell the system to USE |
8 |
> >>> this and that after the system tells me it needs that ... ? |
9 |
> >>> |
10 |
> >>> Why isn't this taken care of within portage itself? |
11 |
> >>> |
12 |
> >>> I don't *want* to decide 32bit or not ... (I like that I |
13 |
> >>> *can* ...) |
14 |
> >>> |
15 |
> >>> I want a (mostly) stable and current linux system with the |
16 |
> >>> necessary choices done by the maintainers ... if Skype needs |
17 |
> >>> it ... ok, then make that a dependency/requirement somewhere ... |
18 |
> >>> but why force me to set that (for so many packages) ? |
19 |
[...] |
20 |
> > There is no good reason whatsoever why portage shouldn't be able to |
21 |
> > treat this like a transitive required USE flag requirement, |
22 |
> > percolating through all libs from the toplevel requirement's |
23 |
> > dependency tree. |
24 |
> |
25 |
> Correct, there is no good reason why portage *can't* do that. |
26 |
> There is a very good reason why portage *won't* do that, it is not the |
27 |
> gentoo way and it goes against gentoo's social contract. |
28 |
> |
29 |
> Portage does not override your choices, and it certainly does not |
30 |
> allow one single ebuild to automagically change the behaviour of |
31 |
> multiple other ebuilds. The correct way to bring about changes in |
32 |
> behaviour is to add your global choices to make.conf (which is |
33 |
> outside the control of the tree), or to add your explicit changes to |
34 |
> package.* |
35 |
|
36 |
It depends what you see as a user choice. In my opinion by writing |
37 |
'emerge skype' to the console the user clearly states his choice to |
38 |
install skype. If he actually cares what that would mean for |
39 |
his system he can use --pretend or --ask option together with --verbose |
40 |
and tweak USE flags if and only if he does not like it. So user has |
41 |
still full control over his system. |
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 |
46 |
|
47 |
We could declare USE settings e.g. in make.conf as overridable by |
48 |
automatic USE dependencies so portage would not see it as incompatible. |
49 |
On the other hand package.use could be non-overridable thus allowing |
50 |
the user to have control over portage choices. |
51 |
|
52 |
> the system owner can enable if you trust portage and the tree to |
53 |
> always make the correct decision - autounmask. You can run it with -p |
54 |
|
55 |
Big advantage of automatic deps over --autounmask is that auto deps |
56 |
would not mess with user configuration files in /etc. Changed USE |
57 |
flags would be stored internally by portage. |
58 |
|
59 |
Robert |
60 |
|
61 |
|
62 |
-- |
63 |
Róbert Èeròanský |
64 |
E-mail: openhs@×××××××××.com |
65 |
Jabber: hs@××××××.sk |