I've been waiting for a good time to put in this comment.
Unfortunately, it's probably several months too late to be useful, and
it probably belongs on tech-userlevel instead of current-users, but I
thought I might mention it anyway.

> rc.d does not fall into this category.  The reason I like rc.d is
> that it improves maintainability in large sites by making it trivial
> for packages (and even built in programs) to install rc hooks simply
> by adding a file.

Has it occurred to people that we could attain this goal, at least
mostly, without changing the way the built-in NetBSD services start
up?  We could preserve /etc/rc and /etc/rc.conf as they were in 1.4.x
and add an rc.d framework used only for add-on packages.  That way,
people who don't install add-on binary packages don't have to deal
with most of the cruft, and NetBSD can feel like a good old BSD system
to those people.

I saw "at least mostly" because the /etc/rc.d stuff would presumably
all start after the /etc/rc stuff, which means if you need to start
something in between native NetBSD services (say, a service which
needs to start before portmapper runs so that portmapper doesn't
assign its port away), you can't.  But I suspect that's less than 10%
of the problem.

This would be similar to how we treat the basic NetBSD system
separately from the package system.  Of course, people who favor
pkg-izing the NetBSD distribution in a fine-grain way probably
wouldn't like the separate rc.d idea either, since it doesn't treat
the operating system and add-on packages in a uniform way.