> But you don't *want* to edit the whole startup process.  You want to
> edit the part you're looking at.

Full agreement. I like the way that on my Slowaris machines that
if I want to mess with Oracle I look at the "oracle" script that
I've added to init.d


> I guess, usage will vary.  init.d is excellent when you want to,
> say, look for nfs or file services - one file will do that work.
> It's hard when you want to find "what starts bazd", because it
> expects you to know what service bazd is associated with.

This is generally a case of someone picking a really cryptic name
for a service or script. Like having the "all singing all dancing
daemon" yet calling the script "foo" in init.d. I feel that this
can be fixed by having a good package toolset as is being
discussed elsewhere.

> It's the old modularity war.  It's harder to find all the pieces of
> a multipart program, but easier to maintain and control.  This applies
> to shell scripts as well as to C.

Quite. I think that the init.d stuff is missing the dependency stuff.
I would like to have two files included in each package.

First we need a script that can go into init.d. This will start or stop
the service on request. It will assume that all the required
subsystems are currently running. And before stopping we will assume
that nothing is going to get the rug pulled out from under it (like
running an rpc app then removing network support without removing
the rpc app)

The second part is a file describing the dependencies that the
subsystem may have. In this way you should be able to issue commands
that start up a subsystem. The start command will lookup the
dependencies, inform the user of what systems are really being
started. Likewise when stopping you will be warned (optionally of
course) of any systems relying on this one.

By doing this we avoid the problems of having the S??foo and K??foo
scripts that SVR4 uses. (which is just avoiding the dependency
problem by passing it onto the user!) We also get the advantage that
new users of NetBSD can install packages without having to
add entries to /etc/rc, just run the install script which auto
starts the application the first time and makes sure that
each subsequent reboot the system comes back.

Just my 0.002p worth

Alex.

-- 
Alex Barclay						Tel: +1 719 535 1455
BT Fraud Systems Development				Fax: +1 719 535 1870
Temporary Address:	1233/117 (C3-1307), MCI, 2424 Garden Of The Gods Rd,
			Colorado Springs, CO 80919, USA
Permanant Address:	MLBG/79, BT Laboratories, Martlesham Heath, Ipswich,
			IP5 7RE, UK