1 |
Holly Bostick wrote: |
2 |
|
3 |
>glen martin schreef: |
4 |
> |
5 |
> |
6 |
>>As an aside, I wonder whether it is a good feature idea that |
7 |
>>ACCEPT_KEYWORDS="<keyword>" emerge <foo> without --oneshot should |
8 |
>>automatically add <foo> <keyword> to the package.keywords file. |
9 |
>> |
10 |
>> |
11 |
>That's an idea with some merit, but imo not enough (merit) to make it |
12 |
>feasible (but it's not my decision; submit a feature request and see |
13 |
>what happens). |
14 |
> |
15 |
>You now know firsthand one of the many reasons that using |
16 |
>ACCEPT_KEYWORDS on the command line is *not* recommended. |
17 |
> |
18 |
>It is a temporary setting, useful only for testing situations. |
19 |
> |
20 |
That makes sense. I hadn't encountered that recommendation at the time - |
21 |
I'd seen the ACCEPT_KEYWORDS syntax without such warning. Not in the man |
22 |
page, obviously, which has it right. |
23 |
|
24 |
> The idea of having the temporary setting invisibly add a permanent |
25 |
> setting seems cool, |
26 |
|
27 |
The trick here is the word 'temporary'. If 'temporary', the keyword --oneshot would (should?) be present. In absence thereof ... It seems analogous to the world file - the world file is the permanent specification, and it written per presence or absence of oneshot. Why not so for /etc/portage/package.*? How are those files different-in-kind from world? |
28 |
|
29 |
I don't know. I am far from an expert at the design philosophy behind these tools. I just note that there seem to be failures of consistency in application (or not) of a flag across different situations. Permanence for one setting is accomplished with a flag (well, absence), permanence for another requires a file change and the flag is ignored. Or there's a failure in my understanding, which I've found to be very well served by saying the wrong things and waiting for stones. |
30 |
|
31 |
> So it's not something for me, but I'm weird ;-) |
32 |
|
33 |
I am too. Without the smiley. Or so is frequently said. |
34 |
|
35 |
glen |
36 |
|
37 |
|
38 |
-- |
39 |
gentoo-user@g.o mailing list |