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 -- [email protected] mailing list
