>For example, one of the problems with /etc/rc.local.d (or
>/etc/rc.d.local - there's an entire flamewar about the name!) is that
>you're then separating your rc.d scripts out. Maybe you can cope with
>that. Maybe it's just an extra imposition on your admin staff by
>saying ``well, use /etc/rc.d/foo start, unless it's something that
>we've installed, and then it's /etc/rc.local.d/foo, or if it's a pkg
>it's /etc/rc.pkg.d/foo.''. It might get annoying. (and that's my
>personal opinion).

This gets back to the issue of separating the collection of scripts from 
where they get used.  In the system I implemented (many years ago now :-)
which was specifically intended to provide rc.d style start/stop facilities
on OS's which didn't normally use it (eg SunOS and *BSD) as well as those 
that did (eg Solaris), I put all the start/stop and utility scripts in 
/etc/rc_d (yes the name sucks, but I needed something which would not 
conflict :-) and on most systems they just got linked into /etc/rc_local.d
but on my NetBSD systems they also got linked into rc.d for boot.

You can split out the runtime location as much as you like, and still
have a central pool for the all important "run /etc/rc_d/squid restart"
which is infact a far more important use of the start/stop scripts
than simple boot/shutdown :-)

Of course my rc.sh, processed $Myname.d so you could link it to /etc/daily
/etc/hourly etc and they all got to benefit from the cool stuff in
/etc/rc_d.  Eg. my DNSMagic toolset uses the same engine for driving
its DNS regression suite and automating complex DNS setups - in 
such a way that customizing what gets run and adding new modules are 
all easily done by the customer without the need to touch any of the 
shipped components (very important :-).  Hopefully the rc.d stuff in
netbsd will prove equally re-usable.

--sjg