"emerge --help config" says CONFIG_PROTECT can be set in make.conf. But on my system this line has ended up in profile.env: export CONFIG_PROTECT='/usr/kde/3/share/config /usr/share/config' and this line has ended up in make.globals: CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" The result of this confusion was that the system has managed to overwrite files I had protected in make.conf: CONFIG_PROTECT="/etc/profile.env /etc/env.d/00basic /etc/fstab /etc/hosts /etc/rc.conf /etc/profile" I'm really tired of nano resurrecting itself in profile.env and 00basic, among other reversions. Wouldn't prudent design assure that there be only one legitimate place to set something as vital to system integrity as CONFIG_PROTECT? If there _are_ good reasons to have it set differently at different times, this needs to be documented up front. Configuration protection should be absolutely controlled.
CONFIG_PROTECT is incremental that means if its defined in profile.env and make.conf and make.globals, it's final value should be something along the lines of: CONFIG_PROTECT="${config_protect from env} ${config_protect from make.conf} ${config_protect from make.globals}" if you seem to be experiencing issues with this, please describe your setup and how it is failing also, the make.conf(5) manpage explains that a few variables are incremental
You say it increments, but make.globals says: # *********************************************** # ** CHANGES TO make.conf *OVERRIDE* THIS FILE ** # *********************************************** That may be wrong for this variable (in which case that statement is partly wrong), but the fact remains that despite having the values I quoted set in make.conf the files /etc/profile.env /etc/env.d/00basic were altered in the course of some emerges, which was particularly noticeable because the EDITOR line reverted from what I'd set it to in both to nano - which I hate - but the issue here is those files are somehow being changed. If I do a "set | grep CONFIG" the value I see for CONFIG_PROTECT is only the value set in profile.env. Since the files in etc which are bein altered should be protected by the values of _either_ make.conf or make.globals, then one of two things is happening: (1) CONFIG_PROTECT is being taken from the envelope, overriding the make.* files and not incremented, or (2) some other process is being triggered which has been granted authority to alter these files. If there's another process with the power to mess things up like this, that's nasty, too.
profile.env is what affects your working environment ... however, when you run emerge, it parses the other files and then sets up the variables based upon the order of which files override other ones. environment > make.conf > make.globals also, CONFIG_PROTECT covers directories, NOT files
Didn't know it covers directories not files. There still looks to be a problem, make.globals has (has always had): CONFIG_PROTECT="/etc ..." So the files in that directory should have been covered - or does it not in fact cover subdirectories? And then do the env.d files through some other process overwrite profile.env? Would also specifying /etc/env.d stop this? The text in "emerge --help config" says that subdirectories _are_ included unless specified in CONFIG_PROTECT_MASK. The only value set for that is /etc/gconf. So there seems to be an error here somewhere. I only ever tried adding the specific file protections because profile.env and 00basic were being altered before I did that. Is there some other process that could be doing this rather than it being a byproduct of emerge? Really annoying to have something in an OS that reconfigures stuff that should be left alone.
CONFIG_PROTECT affects the emerge process ... if an ebuild goes to emerge stuff into /etc, it will not overwrite files due to /etc being in CONFIG_PROTECT however, running `env-update` causes the file /etc/profile.env to be regenerated from the /etc/env.d/* files (which is run after every emerge) if you're saying 'my /etc/env.d/00basic is getting punted', then try this: edit /etc/env.d/00basic to your liking emerge baselayout review /etc/env.d/00basic
az, /etc/profile seems to explicitly set EDITOR to nano. Can we have it set the value based on what's in env.d instead?
was already done ... http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/rc-scripts/etc/profile.diff?r1=1.12&r2=1.13
Yup, "my /etc/env.d/00basic is getting punted"! Before "emerge baselayout": # Copyright 1999-2002 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License, v2 or later # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/env.d/00basic,v 1.6 2002/06/2 0 22:07:37 azarah Exp $ PATH=/usr/local/bin:/opt/bin ROOTPATH=/usr/local/bin:/opt/bin LDPATH=/usr/local/lib MANPATH=/usr/share/man:/usr/local/share/man INFODIR=/usr/share/info CVS_RSH=ssh PAGER=/usr/bin/less EDITOR=/usr/bin/jstar LESSOPEN="|lesspipe.sh %s" After: # Copyright 1999-2002 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License, v2 or later # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/env.d/00basic,v 1.6 2002/06/2 0 22:07:37 azarah Exp $ PATH=/usr/local/bin:/opt/bin ROOTPATH=/usr/local/bin:/opt/bin LDPATH=/usr/local/lib MANPATH=/usr/share/man:/usr/local/share/man INFODIR=/usr/share/info CVS_RSH=ssh PAGER=/usr/bin/less EDITOR=/usr/bin/nano LESSOPEN="|lesspipe.sh %s" # diff /root/00basic /etc/env.d/00basic 12c12 < EDITOR=/usr/bin/jstar --- > EDITOR=/usr/bin/nano So how in heck is that being allowed to happen? Thanks for narrowing it down this far.
nick, martin: what do you guys think ?
ok heres the dilly ... inside of emerge /etc/env.d is added to CONFIG_PROTECT_MASK the reason for this is if a package installs a file there, when env-update is run at the end of emerge the env.d is used basically you're not supposed to touch /etc/env.d if you want to override stuff in profile.env (which is generated from /etc/env.d) then set it in your /etc/profile in this case, move your custom EDITOR value to /etc/profile after the point where it sources profile.env
