Greywolf writes:
> 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:
		read /etc/rc.conf
		if /etc/rc.conf.d/foo exists
			read it in too
		fi

	* /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
change:
	* 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.


Luke.