> I do not want to _have_ to do anything other than drop a new init
> file into a directory, and have it do the right thing.

A question, Chris: do you think crontabs should be similarly reordered
so that you can just drop a script into /var/cron/tabs/root/S97foobar
and have it run?  How about /etc/services?  Should we have
/etc/services.d and let people drop files in there, and have
getservbyname() look things up in all of the files in that directory?

I bring this up because a friend of mine who works in the "real world"
told me that if you're providing binary packages, you want a good way
to add things not just to the startup system, but to cron and services
as well.  If it's really so unacceptable to edit /etc/rc.local during
an installation, and no one will provide software for NetBSD because
of it (even people provided lots of software for SunOS in its day),
then why isn't the structure of cron and services equally
unacceptable, and why shouldn't we brutalize their structure in the
same manner?

(The careful reader will note that /etc/services and the crontab files
are actual configuration files while /etc/rc{,.local} are
Turing-complete shell scripts, and automated editing of the former is
much more robust than automated editing of the latter.  Thus my
argument that system configuration should never be accomplished by
shell scripts... but we don't live in a very ideal world.)

Incidentally, at his company they didn't use the SysV pkg* tools;
their primary goal was to spend as little time on each operating
system as possible, not to have lots of whiz-bang tools to play with
on each operating system.  What they really wanted was a good freely
redistributable package tool which accomplished the above three tasks
for BSD and the various different flavors of System V.