A few weeks ago I summarized the "state of the art" in other modern
Unix-like systems in a message here. I'm going to provide a quick
comparison of the proposal here to those systems.

(for reference, my posting was on 19 March, with Message-Id:
<mtud7orxui2.fsf@contents-vnder-pressvre.mit.edu>, and can be found at
http://mail-index.netbsd.org/tech-userlevel/2000/03/19/0004)

<luke@cs.rmit.edu.au> (Luke Mewburn) writes:

> 3. Reworking the configuration mechanism (replacing rc.conf)
...
> 	My proposal is to replace rc.conf with separate
> 	/etc/rc.conf.d/foo config files, one for each service, with
> 	contents similar to:
> 		foo=NO
> 		foo_flags="-q ex0 -p 667"

This approach most closely resembles Irix, which uses /etc/config/foo
for "on" and "off", and /etc/config/foo.options for the rest. Irix
provides a "chkconfig" command which can test or set the on/off flag,
but has no way to edit the options (whose formats vary wildly by service).

> 	The primary concern with such an approach (and it's one I've
> 	had) is that it's not as easy for a user to manage multiple
> 	services at once (or setup a system from scracth).  If a tool
> 	is provided (e.g, virc(8)) which presents /etc/rc.conf.d/* as
> 	a single editor buffer, which then rewrites /etc/rc.conf.d as
> 	necessary once the editor is successfully exitted, then I
> 	believe that this concern will be addressed.

This is vaguely reminiscent of "rcmgr" in Digital Unix, which can get
or set any shell-style variable in their (monolithic) /etc/rc.config.

        - Nathan