[ On Sunday, December 30, 2001 at 16:53:21 (-0800), Simon J. Gerraty wrote: ]
> Subject: Re: Allowing ${name}_path to be set in "rc.conf", was Re: Keeping /etc/defaults and /etc/rc.d in-sync 
>
> I wish we'd just kept things simple and done the "ugly" init.d and links to
> rc.d/S*foo trick.  Of course, rcorder et al is better than not having 
> start/stop scripts at all.  But we probably wouldn't be having this thread 
> with the init.d model since you can customize the S*foo scripts all you like 
> without needing to be hurt by an update to init.d/*

I'm glad you said that, not me!  :-)

(obviously, as was covered in later replies, the S*foo links need to be
broken and made into copies if they are to be locally customised)

I was certainly thinking of this, which I why I alluded to a more
abstract and more NetBSD-oriented mechanism using /etc/defaults.

Note though that I do like the rcorder scheme just as well.  It's a wee
bit easier to maintain a flexible ordering scheme when the controlling
mechanism is inside of the files being managed, instead of in a series
of filesystem metadata structures.  (you don't need to invent an overlay
mechanism that can be under change control and which will create the
metadata)

I have no qualms about enforcing updates from the source tree with "make
build" or whatever either.  I've been doing that even with the old
system of scripts ever since 1.3.2.  My local changes are made in my
source tree and installed by "make build" so I never worry about
overwriting any of them.  People who update their systems via "make
build" should probably consider this scheme as a requirement.  In fact
I'd be just as happy to move the whole mess to /sbin (except rc.conf)! :-)

Any time you want to manage change in a set of files that might be
installed on many machines and updated from a source tree you either
need to centralise the change management (i.e. in the source tree), or
provide a two stage installation mechanism so that you can safely
distribute and merge centrally managed changes to locally controlled
files.  In the latter case the best design for that intermediate stage
may depend on exactly how the local change management is done, but a
general scheme such as installing into /etc/defaults/rc.d or /etc/init.d
or whatever can always be locally adapted to any CM/merge mechanisms.

-- 
								Greg A. Woods

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