> I'm with der Mouse on the notion that the startup script that gets run
> by init should be a single script - /etc/rc.  One could argue that we

I've said several times that we do not have to consider *.d/* and
changes to init together.  You _can_ have the multiple start/stop
scripts with the current init.  I know, I've got several NetBSD boxes
doing it now...

[For those that dislike *.d for this stuff the reason is so that
you can have a generic script which simplllly knows how to add .d to
its own name (less any .sh) to find the directory it should process.
This is a huge win - I have dozens of modular utilities all diven by
symlinks to the same rc.sh]

> particularly useful.  I do think there *is* a need for an
> /etc/rc.shutdown.  I think that's about it.

That's where anyone running a database or other large application
might start to disagree with you.

> This approach would be a lot of work compared to either sticking with
> the /etc/rc model or switching to the SysV model.   However, as
> several people have pointed out, we could probably get there in
> incremental steps.
> 
> The one important thing from my perspective is that I think it's a
> *bad* idea to put this functionality into init.   Let's keep init
> simple.   I think diverting down the path of making init more
> SysV-like would be a mistake, even if we decide that we want similar
> functionality to what SysV init provides.

As far as I can see the only point in the run-level stuff in SysV is
to have the transition code all run (indirectly) by init and of course
the ability to have vaious things started/respawned by init at various
run-levels. 

Much of this could possibly be done by a separate process I guess -
which could then be optional.  

But again, lets try and separate issues like run-levels from
start/stop scripts and pkg tools.

Most of the aguments I've seen on this tread are actually:  

"*.d/* is cool" vs. "run-levels suck"  

Since we _can_ have one without the other, lets debate them
separately.

--sjg