Subject: Re: /etc/rc.conf and upgrading
To: Robert Elz <kre@munnari.OZ.AU>
From: Simon Burge <email@example.com>
Date: 10/13/1999 10:11:06
Robert Elz wrote:
> If any of this is going to make rc.conf.local mandatory, then I don't
> really think it is a good idea.
Under this scheme rc.conf.local wouldn't be mandatory, in the sense that
at long as the variables are set in either rc.conf or rc.conf.local
we'll be happy.
> I would also have rc.conf check for rc.conf.local and source it if
> it exists, rather than doing it in /etc/rc - that way everything that
> reads rc.conf will get the local additions.
Reasonable... A few people suggested that as well.
> I would also tend to attempt to avoid the "config file turns into a
> distribution file" syndrome - that's where a file (or directory) that
> was created for users to set up their configuration, then gets distributed
> with a sample configuration, and then people want to avoid touching
> as otherwise the next system update with an updated sample will blow away
> the local changes. Then the once configuration file becomes an untouchable
> data file, and a new file is needed for configurations, and the whole
> thing repeats...
This thread started when I suggested having an /etc/rc.defaults (someone
suggested /etc/rc.conf.defaults), and then /etc/rc.conf would be just
what the user wanted to override. This avoids the "the file changed its
purpose in life" problem.
> A better procedure is to simply come up with an update procedure that allows
> the user updated file to be updated when the system is upgraded. For rc.conf
> that might be as simple as adding a few lines of comments between each line
> that users are likely to edit, then applying judicous use of patch to make
> updates (the comment lines serving as invariant delimiters for patch to match
The lack of simple update procedure is what's driving this. Having
an update procedure that can be used automatically without user
intervention (hmm, a tautology) doesn't appear to be that easy...
Predicting which bits users are likely to edit will be fun - users
will be users and do the exact opposite of what we expect!
Maybe we need /etc/rc.d :-) (ducks)