> [ ... rc.conf ... ]
>
> How about naming these variables `_RCGEN_FOO=foo' and have the generating
> script search the environment for `_RCGEN_*', chopp of the prefix and
> insert the result in `rc.conf'?

I don't particularly like this, because:
	(1) I think it's ugly, and
	(2) I don't see how it helps solve the problem.

If you do this, then you need to do it in such a way that there exists
some program that takes the current rc.conf, reads it to find out
what's currently in it, replaces the current contents with the new
ones, and writes out the new version.

If you do it what i'd call the 'normal' way, with the shell, then you
only need one 'program': the script to generate rc.conf.  You can
simply source the existing rc.conf, change any variable definitions,
and source the program (it should probably be a shell script, to avoid
environment hassles).


Doing it in a way where you pick properly-prefixed variables out of
the environment also makes rc.conf a bit harder to manipulate from
shell scripts...  consider, for example, what you'd have to do with
each method to add a new network interface.


> This way you can include it in, say, rc.local too to deal with "package"
> configurations.

I think that, while /etc/rc.conf may be a good idea for the 'system
package,' other packages should have their own configuration files.

Why try to stuff everything into one file, when you don't have to and
when it doesn't make much sense to?  How do you then deal with
possible name conflicts?  How can you add comments to the
configuration files, in any sane way?

(Of course, i believe that rc should be split up into init.d scripts,
too...  8-)


chris