Scott Aaron Bamford wrote:

> so scripts would parse rc.conf before it parses its rc.conf.d/ file (i think
> someone sugested this always happen anyway to have the `backwards compatable'
> feel), with sh this meens values in rc.conf.d/ override any in rc.conf
> and so they are the authroity.

  While I don't have strong feelings either way (using rc.conf.d/ or
rc.conf), this doesn't feel right to me.  Having both rc.conf _and_
rc.conf.d/ with the latter being authoritative is error-prone to uses
who are accustomed to the old scheme.  A lot of people are going to end
up wondering why their manual changes to rc.conf (using vi, not virc,
mind you) don't show any effects.

  Why not have virc create a 'virtual' rc.conf (i.e., some mkstemp()
filename) that can be edited and then is re-distributed into rc.conf.d/
?  This way, chances of people using the wrong editor on the wrong
config file are a lot smaller!  We could even install an rc.conf file
that says "this file is obsolete, please use virc to edit system
configuration".

  The only thing I can think of, that's not handled by this method are
additional config parameters that are contained in none of the
rc.conf.d/* files.  However, these could easily moved to some
rc.conf.d/config.default (or whatever) file.  IMHO this is far less
error-prone than having an rc.conf around that duplicates all config
variables and can be too easily changed using vi.

  Just my $0.02 ...

  Cheers
      ,
   Rene