Subject: Re: /etc/default ickiness...
To: Luke Mewburn <>
From: Mason Loring Bliss <>
List: tech-userlevel
Date: 09/10/2000 23:16:34
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 10, 2000 at 11:29:06PM +1100, Luke Mewburn wrote:

> I hope that helps to explain why I made the change. I feel that it
> will provide benefits in the long run for ease of management and
> easier upgrades of /etc/{daily,weekly,monthly,security,rc}.conf
> that we've provided in prior releases or even within -current.

Yes. I agree that it's a useful change. My only concern is that we
now by default won't have people editing our nicely documented rc.conf

My thought about virc is that it should be an option, but certainly
not required. I'm thinking about doing one with enough smarts to
read in and merge custom settings in /etc/rc.conf and then spit out
the minimal rc.conf to describe the differences between the user's
settings and the default settings, with the file it spits out being
identical to the current /etc/rc.conf, current meaning the one that
reads in /etc/default/rc.conf.

This brings up one question, however. How common is it to include logic
in /etc/rc.conf, beyond

	if [ -r /etc/default/rc.conf ]; then
		. /etc/default/rc.conf

? My reason for asking is that if there's no logic included other than
this, it'll be relatively easy to have virc do the right thing and
generate a list of Bourne shell variable assignments. I haven't thought
of any way to handle /etc/rc.conf scripts with any sort of logic above
and beyond the bit listed above, though.

To reiterate, the virc I'm considering would be completely optional,
and would work invisibly and interchangably with doing it by hand...
Thanks in advance for ideas.

    Mason Loring Bliss  They also surf who
awake ? sleep : dream;  only stand on waves.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.2 (NetBSD)
Comment: For info see