| 1 |
glen martin schreef: |
| 2 |
> |
| 3 |
> As an aside, I wonder whether it is a good feature idea that |
| 4 |
> ACCEPT_KEYWORDS="<keyword>" emerge <foo> without --oneshot should |
| 5 |
> automatically add <foo> <keyword> to the package.keywords file. |
| 6 |
> |
| 7 |
|
| 8 |
That's an idea with some merit, but imo not enough (merit) to make it |
| 9 |
feasible (but it's not my decision; submit a feature request and see |
| 10 |
what happens). |
| 11 |
|
| 12 |
You now know firsthand one of the many reasons that using |
| 13 |
ACCEPT_KEYWORDS on the command line is *not* recommended. |
| 14 |
|
| 15 |
It is a temporary setting, useful only for testing situations. The fact |
| 16 |
that if you use it, then decide to make the testing situation permanent |
| 17 |
but do not add a permanent setting (in package.keywords), you will |
| 18 |
encounter problems of this sort underlines the nature of the setting |
| 19 |
(temporary, temporary, use for explicit testing only; if you want a |
| 20 |
permanent setting, make one explicitly). |
| 21 |
|
| 22 |
The idea of having the temporary setting invisibly add a permanent |
| 23 |
setting seems cool, but undermines both the function of the temporary |
| 24 |
setting (since it's no longer truly temporary), and the function of the |
| 25 |
permanent setting (since you have not explicitly made the setting, you |
| 26 |
may or may not want it set), and what about dependencies? You'd have to |
| 27 |
unmask them explicitly (or else you'll get a lot of "thus and so cannot |
| 28 |
be installed because thus and so is masked" errors, and if you have to |
| 29 |
do that, you've already destroyed any usefulness an automatic addition |
| 30 |
might have had. |
| 31 |
|
| 32 |
So it's not something for me, but I'm weird ;-) ; others might feel |
| 33 |
differently. |
| 34 |
|
| 35 |
Holly |
| 36 |
|
| 37 |
|
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-user@g.o mailing list |
Archives