From owner-freebsd-hackers  Sun Jun 25 12:34:30 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id MAA04080
          for hackers-outgoing; Sun, 25 Jun 1995 12:34:30 -0700
Received: from rover.village.org (rover.village.org [198.137.146.49])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA04073
          for <hackers@FreeBSD.ORG>; Sun, 25 Jun 1995 12:34:26 -0700
Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id NAA03700; Sun, 25 Jun 1995 13:34:11 -0600
Message-Id: <199506251934.NAA03700@rover.village.org>
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Subject: Re: Announcing 2.0.5-950622-SNAP 
Cc: hackers@FreeBSD.ORG
In-reply-to: Your message of Sun, 25 Jun 1995 11:22:44 PDT
Date: Sun, 25 Jun 1995 13:34:11 -0600
From: Warner Losh <imp@village.org>
Sender: hackers-owner@FreeBSD.ORG
Precedence: bulk

[[ Cc's trimmed to Rod and hackers ]]

: I have about 12 pending changes to the /etc/sysconfig and related
: scripts, some intergrated and tested on my box, others needing some
: clean up, others needing some testing to make sure what is being
: done actually works well.

One idea that I had was something like this:

If you ship a "template" /etc/sysconfig, called /etc/sysconfig.tmpl
that looks like:

	#
	# blah blah blah
	blahflags=%blahflags%
	# bar bar bar bar baz bong!
	barflags=%barflags%

then you could fairly easily edit that file between releases.

What does that buy you?  Well, if you were to also have a
/etc/sysconfig.default for each release, you could generate the
/etc/sysconfig automatically by having a shell script thta looked
something like (this is for illustration purposes only):
	#!/bin/sh
	mv /etc/sysconfig /etc/sysconfig.old
	. /etc/sysconfig.default
	. /etc/sysconfig.old
	cmd=
	for i in `cat /etc/sysconfig.vars`; do
		cmd="$cmd;s/%$i%/${$i}/g"
	done
	sed -e "$cmd" < /etc/sysconfig.template > /etc/sysconfig

That way, you'd get the default values, with the user's current values
overriding them (in case things get added, you'll want this), and
you'd have the /etc/sysconfig file be upgradible.

A more elegant solution would use m4, but not cpp, since it isn't well
suited for things like this.  Yes, Imake has been made to work for the
X world, and it works relatively well, but much time and heartache
would have been avoided if they had gone the m4 route, IMHO.  This
from someone who has actually written a full set of Imake template
files for the last company I worked for.  The sendmail config files
are also a pain, but less of a pain than imake files.

The only down side to this approach is that comments in /etc/sysconfig
would be lost.  This may or may not be acceptible.  Oh, if you added
additional system parameters that the template didn't know about, then
you'd also lose those.

I do agree with the /etc/fstab, /etc/ttys, /etc/gettytab, etc comments
that Rod made as well.  They should be separate files, since separate
programs use them.  /etc/sysconfig should be for all shell scripts
started from /etc/rc.

One additional problem is /etc/rc.local.  I don't recall what is
shipped by default, but I seem to recall that there was some code in
that file that should be preserved in an upgrade.  By its very nature,
it is hard to quantify its contents in an /etc/sysconfig way.

Comments?

Warner