Subject: Re: /etc/default ickiness...
To: None <email@example.com>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 09/17/2000 17:34:25
> You know, I was going to hop on the bandwagon down the flame-licked
> bumpy road and decided that it wasn't worth the grief. It still isn't.
> I just tried the new scheme (i.e. it looks at default/rc.conf and applies
> overrides in rc.conf), and overall I'm actually pleased with this.
> I'm not thrilled about the rc.conf.d stuff suddenly showing up, but
> at the moment it appears that actually USING rc.conf.d is optional.
> If this was by design, I will say kudos and THANK YOU to Luke for
> the work he's put in here -- I don't envy him what he's had to put up
> with in the form of abuse from myself (among others) on this road.
> He's been kind enough to either respond nicely or completely ignore it,
> at least to me.
After much discussion on this topic (splitting out the config files for
each application separately) we (myself, fvdl, & others involved in
rc.d) decided against that because of the angst involved.
What we have now is (as discussed at other times, but reiterated here
for Greywolf's warm n fuzzies):
* /etc/rc.subr provides load_rc_config(), which:
if /etc/rc.conf.d/foo exists
read it in too
* /etc/rc.conf (and /etc/default/rc.conf) provides the config
for the base system.
* /etc/rc.conf.d is there in case it makes things easier for
pkgsrc or a local sysadmin to manage local config on a per
script basis, but its use is not mandatory.
FWIW: I actually did the work to split all of the existing rc.conf into
rc.conf.d/foo, and realised it was not going to be justified as a
* a lot of the existing rc.conf variables probably need
renaming to be consistent with the program/ or rc.d script name
* it was a lot more annoying to configure & manage
* other reasons
So I saw the light (hi mrg! :) and tossed it.
> I like /etc/default/rc.conf + /etc/rc.conf. The re-tuning of startup
> for me actually took less time to do this way than it did last time
> I had to retune it.