Darren Reed writes:
> "reload/restart" would be another useful one.

`restart' is built in by default (does `stop' then `start', unless
otherwise specified). `reload' is only supported if asked for, because
it doesn't make sense in all contexts.


> > 	* Implementers should be able to add extra actions to a
> > 	  script (e.g, `reload', `debugon', etc) fairly easily.
> 
> Any `additions' should be standard across all scripts which are
> NetBSD derived (vs 3rd party) - even if they're null ops so that
> invalid actions always return errors.

???. if you do /etc/init.d/foo blah and foo doesn't support blah,
you'll get an error; this is what i'd expect. do you want every
script to support every option that another script needs (e.g,
`named' might support querylog, debug, etc)?


> > 		    a) prior art (cf. SYSV), and people are used to running
> > 			/etc/init.d/foo start
> 
> Or /etc/rc2.d/foo start
> And what about /etc/rcS.d ?

`prior art' to me is solaris/irix; deal with it ;-).  if you want rc2.d
or rcS.d because that's what you're used to, then MAKE A SYMLINK!


> > 		for i in `rcorder /etc/init.d/*`; do
> > 			$i faststart
> > 		done
> > 	(`faststart' is like start but without the check for
> > 	running processes).
> 
> "faststart" seems like a bad idea to me.  It seems to me something
> like what you'd use in testing, but that's about it.  Or maybe you'd
> use it when booting a vax so that it boots `today' ;)  Granted this
> is pretty much what we do today, but who's to say that's something
> to brag about ? :->

faststart is a `backdoor' just for the startup scripts, because we
`know' that the process won't be running so we don't waste time doing
the `ps' check. if a user does `/etc/init.d/foo faststart' when foo
is already running and then they get screwed, THATS THEIR FAULT, because
it's not supported `clueful' behaviour post-boot.


> > 	# PROVIDE: mountd
> > 	# REQUIRE: beforemountlkm network portmap
> 
> Is that meant to mean "before mountlkm" or "before mount lkm" ? Or is
> "beforemountlkm" really the name of a single script ?  If it's the latter
> then the name just sucks.  If either of the former, split it up.

[beats head against wall.] this project is not going to be held up
because someone has a hangup about what the name of a script/variable/
whatever is...


> On the whole good, but I've got one major criticism:
> 
> in an effort to not piss anyone off (too much) there's too much fence
> sitting being done.  I don't mind the /etc/rc still being supported
> (the everything in one script version) but the rest is of concern.
> There's an /etc/rcX.d which gets used sometimes and an /etc/init.d
> which also gets used sometimes.  It's possible to have a /etc/rcX.d
> populated but then ignored by a script which independantly interrogates
> scripts in /etc/init.d.  From a featurism point of view, sure, it's
> great that we've got all these features, but I think these two are
> competing with each other and offer no real long term benefit.  We
> need to pick one and go with it.  I think this is trying to be everything
> to everyone and ultimately we'll lose.

but you're asking for stuff that's effectively fence sitting as well!

.

netbsd will ship with *one* method of running rc, but provide the
system administrator with the flexibility to choose from a couple of
others if they so desire. saying that we shouldn't support this
flexibility is like saying we shouldn't support anything other than
sendmail (vs postfix/qmail) , /bin/mail (vs 100s of MUAs), /bin/sh
(vs csh/zsh/tcsh/bash), etc. it doesn't cost us that much, and gives
us the `win' that system administrators think our system is flexible.

imho, the only real valid point i've seen in this thread so far is
hubert's regarding how to support packages; i genuinely forgot to
mention some thoughts on how to address that (and will do so RSN). the
rest of the discussion appears to be hair splitting about personal
preferences, or other `problems' that were already solved but i forgot
to document them in my initial post; if you read the source you'd see
it wasn't an issue...

(slightly grumpy) luke.