Subject: Re: Posible virc(8) implementation
To: Scott Aaron Bamford <email@example.com>
From: Dr. Rene Hexel <firstname.lastname@example.org>
Date: 05/04/2000 07:58:08
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
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 ...