Subject: Re: /etc/default ickiness...
To: Luke Mewburn <lukem@netbsd.org>
From: Mason Loring Bliss <mason@acheron.middleboro.ma.us>
List: tech-userlevel
Date: 09/10/2000 23:16:34
--oLBj+sq0vYjzfsbl
Content-Type: text/plain; charset=us-ascii
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
file.

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
	fi

? 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.

--=20
    Mason Loring Bliss  mason@acheron.middleboro.ma.us  They also surf who
awake ? sleep : dream;  http://acheron.ne.mediaone.net  only stand on waves.


--oLBj+sq0vYjzfsbl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE5vE6SykMMY715wXIRAvcSAKDvx9di9nqA4KSQV6VVz3J1j+/hgACgu4dS
7b+Jsb9eva+hhzFWz4Avp54=
=n3m7
-----END PGP SIGNATURE-----

--oLBj+sq0vYjzfsbl--