Dale schreef:
> Holly Bostick wrote:
>
>
>> There is, of course, "an option to tell it to"; you just don't know
>> about it :-) .
>>
>>
>
>
> You're kidding right. Something that I don't know about, yea right.
> LOL LOL Treat me like a sponge, I'm absorbing your knowledge, I
> hope anyway. I have been using Gentoo a while and have a little
> understanding of how it works but not much. I just know it is better
> than winders.
>
>
>> You might want to have a closer look at the Gentoo Documentation
>> pages, most specifically
>>
>> Gentoo Linux Documentation -- Environment Variables at
>> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5
>> .
>
> That link didn't make sense. That the right chapter? May just be
> me. LOL
>From the link; under "Important Examples"
CONFIG_PROTECT This variable contains a space-delimited list of
directories which should be protected by Portage during updates
.
CONFIG_PROTECT_MASK This variable contains a space-delimited list of
directories which should not be protected by Portage during updates.
>From man make.conf, under variables:
CONFIG_PROTECT = [space delimited list of dirs]
All directories that are defined here will have "config
file protection" enabled for them. For more information, please see
`emerge --help config`.
CONFIG_PROTECT_MASK = [space delimited list of dirs]
All directories that are defined here will have "config
file protection" disabled for them. For more information, please see
`emerge --help config`.
>> In any case, the deal is configuration files are protected by
>> default.
And the CONFIG_PROTECT and CONFIG_PROTECT_MASK variables are how it's done.
<snip>
>
>
> It is no suprise that I didn't know about it, yet. I did a man
> emerge and didn't see it. Is it a newer version that I don't have
> yet? I run stable packages.
Did I say man emerge? I meant man portage... oops, wrong again, should
be man make.conf.
>
>> But the thing is, such files are important enough that they
>> shouldn't be just deleted like it's nothing. That's the Gentoo
>> design and the Gentoo way; an action like deleting /etc/devfsd can
>> have sweeping consequences if the system is not prepared to pick up
>> the ball with udev-- forcing you to delete it manually is both a
>> way of making sure that you know you did it, and also making sure
>> you know what you're doing before you do it (90% of the users ask
>> the list before taking any action, which is fine-- we *want* people
>> to know what they're doing and have a healthy respect for their own
>> power to bork their system, so good you ask first!)
>>
>
> I have been running udev for a while and it seems to be working fine.
> Time for devfs to go.
Indeed. It's continued presence is shortly going to start causing you
problems if it hasn't already. There was a 'grace period' where they
were allowed to co-exist; that grace period has ended for unstable users
not long ago, and stable users with both systems installed will be
seeing issued as devfs finally goes definitively from 'deprecated' to
'obsolete'.
So yes, it's time for it to go.
>
>> In any case, yes you can override the setting (of *course*, this is
>> Gentoo!) to delete certain (or all) protected files after an
>> unmerge of various programs; but now you have to look up how to do
>> that, and that means you have to read a bit about the consequences
>> of your proposed action before taking it (since you don't know how
>> to take it before you read a bit)
>>
>
> I cheat. When I know I am about to delete some config files that I
> worry about, I back-up my /etc directory. I save it until I reboot a
> few times just to make sure. Smart huh?
You're one of the few.... I mean, it's extra work for you, and not
really necessary, but better that you should do a little unneccessary
extra work than bork everything. Better safe than sorry, as it were.
But I'm sure you know how many computer users don't take any precautions
whatsoever to protect themselves from system error, or human error.
Doing so is not 'cheating', it's just good common sense.
Holly
--
gentoo-user@gentoo.org mailing list
