[ On Friday, September 15, 2000 at 16:36:52 (-0700), John Nemeth wrote: ]
> Subject: Re: /etc/default ickiness...
>
>      Your solution really doesn't help me much (I have many machines
> spread all over the city to maintain).  You make more work for me,
> since I have to look in one file and then make changes in another
> file.  At upgrade time, I need to compare the old and new /etc/default
> files to see what has changed in order to make any necessary changes to
> the /etc files, which is an additional step that wasn't there bofore.
> Or, I could just start my /etc files from scratch.

That's because, as you admit below, you're making your own life harder
on yourself!  :-)

If you simply put only the locally changed variables in /etc/rc.conf and
leave the rest alone (i.e. in /etc/default/rc.conf) then you might not
have to do *anything* on an upgrade but reboot into multi-user mode!

Imagine that!  Nothing at all!  Just upgrade and boot!

(It really does work in practice for patch releases, though often with
point releases there are likely to be so many new things that you'll at
least want to check the new defaults and no doubt some variable names
may even have been deprecated too, etc.)

> } Except that if you don't like what we have now, you can do this:
> } 	cp /etc/default/rc.conf /etc/rc.conf
> } and you're back to where we used to be, sans the rc.local.conf stuff
> 
>      I just may do that.

Don't do that!  It really is much much easier in the long run to only
put changed values in /etc/rc.conf and leave *everything* else out.  Any
modern full-screen text editor will easily allow you to simultaneously
view two files and to copy selected bits of one file to the other.  Even
without such modern conveniences the additional effort of first
appending the entire default file to the primary one and then deleting
all un-changed entries afterwards is really quite trivial.  I.e. do do
this instead:

	cat /etc/default/rc.conf >> /etc/rc.conf
	vi /etc/rc.conf

If you then insert a marker comment on all the lines you change it'll be
really easy to delete all the lines you didn't change and you'll be left
with the same result you'd get if you had only added the changed entries
to the file in the first place.

>  However, I recall a discussion about
> rc_configured that indicated that it might not be that simple.  I'll
> have to look into it.

You'll be obliterating the critical part of the default /etc/rc.conf if
you clobber it with /etc/default/rc.conf -- append the latter instead.

>  I don't really care about the rc.local.conf
> stuff.

That doesn't even exist any more, but it could be locally added again of
course if you share your localised rc.conf with several machines for
site-wide consistency but still want to allow for machine specific
localisations too.

>      It should be a useful reference for inexperienced people, but it
> shouldn't be needed by people that are experienced.

Once you're experienced with the new rc.conf then you won't need to read
about it any more, but for now everything is new and you are by
definition not experienced with it so read away, learn, and enjoy!

>      I think the suggestion I made of leaving the /etc files alone and
> stashing a copy in /etc/orig would make adminstration easier and would
> make the development of a merging tool easier.  Your current
> /etc/default scheme would probably make the development of a merging
> tool easier, but it does so at the cost of making administration
> harder.  This is the wrong way to do things.

There's literally no real difference between your /etc/orig and the
existing /etc/default (except that one could in theory make changes to
/etc/default files and potentially cause the behaviour of the system to
change -- I suppose sysinst could "chflags schg /etc/default/*" to
prevent that from happening easily though).

The /etc/default scheme does not make creation of a merge tool any
easier at all in fact.  What it does is to make upgrades much easier
*without* a merge tool.

A merge tool is trivial to devise if it can assume that an original copy
of the file has been squirrelled away for its future use at sysinst time
(perhaps on a non-default branch in an RCS file) and thus allowing it to
perform a standard 3-way merge (with diff3) when given a new copy and
the localised copy.

I.e. the /etc/default scheme is never the wrong way (and since it
logically identical to the /etc/orig scheme you would prefer even you
cannot make a logical argument against it), but it is not necessarily
the best way if you've already got a tool to handle upgrade merges.

In the specific case of a localised /etc/rc.conf that only modifies the
values inherited from a master /etc/default/rc.conf there is perhaps
some need for a tool that can verify that an upgrade does not change a
configuration.  Such a tool is almost too trivial to write though since
any experienced person should be able to invent it on the spot, but
since it needs a few temporary files it might best be turned into a
script:

	: ${TMPDIR:=/var/tmp}
	( set > $TMPDIR/$$.base )
	( . /etc/rc.conf ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.oldconf )
	mv /etc/default/rc.conf /etc/default/rc.conf-OLD
	mv /etc/default/rc.conf-NEW /etc/default/rc.conf
	( . /etc/rc.conf ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.newconf )
	( . /etc/default/rc.conf-OLD ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.olddef )
	( . /etc/default/rc.conf ; set | cat - $TMPDIR/$$.base | sort |	uniq -u  > $TMPDIR/$$.newdef )
	comm -13 $TMPDIR/$$.oldconf $TMPDIR/$$.newconf > $TMPDIR/$$.chgvar
	comm -13 $TMPDIR/$$.olddef $TMPDIR/$$.newdef > $TMPDIR/$$.newvar
	comm -23 $TMPDIR/$$.chgvar $TMPDIR/$$.newvar

If I'm not mistaken (the above is not tested in any way and my set
theory is a bit rusty it seems), the output should be just the default
configuration items changed by the upgrade and not already overridden by
local settings, excluding any new items that would not have been
mentioned in the old files.  In an upgrade the output should probably be
empty in fact.  If you want to change the defaults in any of the new
configuration items then $TMPDIR/$$.newvar should be where you look for
the list of such items.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>