Re: [gentoo-user] emerge --newuse misses package that new USE affects

[Holly Bostick]

glen martin schreef:
> Holly Bostick wrote:
>
>> glen martin schreef:
>>
>>> As an aside, I wonder whether it is a good feature idea that
>>> ACCEPT_KEYWORDS="<keyword>" emerge <foo> without --oneshot should
>>>  automatically add <foo> <keyword> to the package.keywords file.
>>
>> That's an idea with some merit, but imo not enough (merit) to make
>> it feasible (but it's not my decision; submit a feature request and
>> see what happens).
>>
>> You now know firsthand one of the many reasons that using
>> ACCEPT_KEYWORDS on the command line is *not* recommended.
>>
>> It is a temporary setting, useful only for testing situations.
>
> That makes sense. I hadn't encountered that recommendation at the
> time - I'd seen the ACCEPT_KEYWORDS syntax without such warning. Not
> in the man page, obviously, which has it right.
>
>> The idea of having the temporary setting invisibly add a permanent
>>  setting seems cool,
>
> 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?


OK, I'm not an expert either, but I *think* that the issue is the fact
that ACCEPT_KEYWORDS and emerge are *two separate commands*.

Are you familiar with exporting variables? ACCEPT_KEYWORDS is, of course
a variable. When you export a variable (DISPLAY, LD_ASSUME_KERNEL,
LD_LIBRARY_PATH, LD_PRELOAD, PS1, ACCEPT_KEYWORDS), the
variable is changed for the current login shell session, but is not
persistent. Period. That has nothing to do with Portage or any program,
that's how Linux works. Variables are permanently set in configuration
files (in the case of ACCEPT_KEYWORDS, in /etc/make.conf, with
modifications allowed from /etc/portage/package.keywords).

Most of the time, the temporary nature of this change can be assumed
without thinking-- if the startup script for Neverwinter Nights includes an

export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH

command, the fact that it's temporary doesn't matter, because it only
needs to be in effect while I'm running Neverwinter Nights, which is a
temporary condition.

This is completely different from the state of the Portage tree and your
world file when running emerge. Basically, when you use ACCEPT_KEYWORDS
on the command line, you are changing a variable temporarily, which
Portage then reads, but because the condition does not persist-- and the
state of Portage variables must persist across sessions-- you're
essentially confusing Portage, which must rely on you to have a stable
list of variable conditions in order for it to know what it's doing.
This is not a flaw in Portage, it's just how it's constructed, and it
really couldn't be constructed any better than it is-- it already does a
lot more than one might have thought possible in terms of being flexible
and 'pushing the envelope'.

But the conditions of the environment must be respected. There is no way
for Portage to become aware that you exported a variable prior to
running the emerge command, and so there is no way for Portage to
automatically add the --oneshot switch if you had done so, in the same
way that "--update implies --pretend" or whichever switch it is that
implies another, so the second switch is automatically added if the
first is present. Because (export) ACCEPT_KEYWORDS is not part of the
emerge command, and the emerge command can only adjust itself, based on
its own settings, not other settings that you have manually adjusted
prior to running the command.

If you see what I mean.

Anyway, I could be totally wrong, but I think it hangs together, and I
suspect it is in fact the case.

Perhaps it could be better explained to people, though, so that they
understood the relationship between the variables that Portage is
reading and the commands that one might run to modify them. Of course, a
good thorough grounding in shell operations would take care of that,
too, I suppose....

Holly
-- 
gentoo-user@g.o mailing list