Date:        Wed, 13 Oct 1999 10:11:06 +1000
    From:        Simon Burge <simonb@NetBSD.ORG>
    Message-ID:  <199910130011.KAA20126@balrog.supp.cpr.itg.telecom.com.au>

  | This thread started when I suggested having an /etc/rc.defaults (someone
  | suggested /etc/rc.conf.defaults), and then /etc/rc.conf would be just
  | what the user wanted to override.  This avoids the "the file changed its
  | purpose in life" problem.

That can be achieved without two files (which then create confusion as
to what overrides what) by making "checkyesno" smarter, so it gets given
the variable name (instead of its value), and what NetBSD wants to be the
default value for it, and if the variable isn't set, returns the default.
That way rc.conf only ever needs to contain overrides (and the default
settings are kept where the value is used, so it is all together).

I'm not saying that's the best way forward, just that it woudl be one way.

  | The lack of simple update procedure is what's driving this.

If/when i find some time I might look at doing what is needed for
this - I don't really think it is all that difficult to manage.

But ...

  | Having an update procedure that can be used automatically without user
  | intervention (hmm, a tautology) doesn't appear to be that easy...

No, that's impossible - if the system has been upgraded, then users are
quite likely to want to change their minds about some earlier conf options.
Eg: feature X might have been disabled because it was considered too buggy
or useless, or whatever - but after an upgrade, it might be fine, and the
user wants it on.    There's no way this can possibly be avoided.

  | Predicting which bits users are likely to edit will be fun - users
  | will be users and do the exact opposite of what we expect!

Clearly prediction isn't the way to go - coping with any changes that
the user may have made is.   That means that as long as the NetBSD
defaults remain unchanged, any user update of that default ought to be
fairly painlessly carried forward.   Similarly, if NetBSD decides to
change the default, and the user has just been using the default, then
the update should be incorporated (one hopes that NetBSD doesn't go
arbitrarily changing the default settings without good reason).  If
both the user and NetNSD have changed in the same way, then everyone
is happy...

  | Maybe we need /etc/rc.d :-)  (ducks)

There's nothing wrong with rc.d (other than the stupid name) - that is,
as a concept.   The implementation (and the directory naming) as invented
by SysV (or Sys 3 really) are brain dead - but the idea of having a
directory full of scripts to run to start applications is just fine
of itself.   In fact, I thought that someone was already working on a
scheme to set things up that way already.

Unfortuantely, that has nothing whatever to do with the current problem.
That affects what is in /etc/rc (and rc.local).   Something, somewhere,
somehow, has to decide what is enabled, and what is not, and what the
defaults will be.  And the user has to be able to change those defaults.
Whether that is done by the existance of files in a directory, or the
existance of X=YES lines in some file or other really makes no fundamental
difference - all the hard problems are exactly the same.

kre