Subject: An observation about rc.d (was Re: run levels)
To: Perry E. Metzger <email@example.com>
From: Greg Hudson <ghudson@MIT.EDU>
Date: 04/24/2000 01:39:38
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.