"Joel Baker" <[EMAIL PROTECTED]> writes: > This brings us back to Debian-Policy, which is quite explicit about what > must be done by init (though, thankfully, it doesn't declare *how* it must > be done). Please see the Policy Manual, section 10. Unless we intend to > move all of Debian to this init (hey, if you think it's that much better, > convince them),
I actually do think its that much better. However, it is pretty trivial to simulate System V stuff with a shell script that calls the various rc?.d scripts. What isn't trivial to simulate for real is actual run levels, but the scripts are trivial. This may, of course, simply be a place where NetBSD and Debian should agree to disagree. Though I doubt we'd be able to convince core Debian to pick up our init and rc system, I'd recommend having a look at the way that it works. We designed it based on having used all the other systems and deciding they weren't what we needed. Like the System V rc system, there is a separate script for each facility, but unlike System V, there is no arbitrary numbering to handle the ordering. The Debian policy manual, I'll note, doesn't tell you how to number your scripts. You have no way to know, really, what number corresponds to "disks mounted" or "named running" or whatever. Is that S28 or S72 that you want? What happens when new packages get installed? Does it change the ordering you want? The way you figure out what a given init script should be named is purely by lore and what is in the system already. In our system, you *do* have a natural way to specify "this program should be executed after the network is up but before users can log in", or "this daemon depends on named" or what have you, and it is easy to read, too. If you want to make sure that sshd can only start after the point where user logins are permitted (reasonable, eh?) you do # PROVIDE: sshd # REQUIRE: LOGIN in /etc/rc.d/sshd. I won't claim we'll ever convince other Unixen to adopt it, but it is MUCH nicer. The code is all open source, too, and very simple to understand. FreeBSD is adopting it because they've seen it and they like it a lot. The problem is, of course, that it isn't what a naive System V administrator will expect. It is very easy to learn, and much easier to use, but it isn't identical to the other system. We've gotten serious flames about this, and in many ways the flames are right -- being different is a difficulty for people. We don't do what's in their books. In general, the BSD way traditionally has been to try to do the "right" solution rather than always the "most compatible" solution, which is not always the popular move. We may not be able to all use the same solution in the end, but do have a quick look at how ours works. Maybe we can get most of what you want without having to get a new init working. -- Perry E. Metzger [EMAIL PROTECTED] -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/
