I've been following the conversation on run-levels and /etc/rc?.d and have a couple of comments to make.
First, we need to recognize that each approach has it's own strengths and weaknesses. No matter which solution is chosen, there will be some trade offs. Second, I think we need to separate implementation from the interface. Whether Debian stays with the current behavior, adopts a State machine approach, or a Stack of States approach, is independent of the interface provided to the packages. The single-file interface to run-levels makes sense to me. It is often better to have information centrally located. It certainly can ease administration. I think having a utility that reads one file in order to manipulate the various files and links associated with the numerous run-levels makes sense. Having one config file means that the package maintainer, or installer, or the system administrator only has to tell Debian *what* they want and let Debian determine *how* to do it. It's the same philosophy we use for adding users and groups - the package maintainer doesn't create the home directories, the sys admin doesn't add entries to /etc/password - Debian does that for them. This is a sound philosophy that I think needs to be exploited more. If Debian makes it easy for packages (or maintainers, or installers) to select the desired run levels for a given service, then how it's implemented becomes less of an issue for the end-user. The fact is, the end-user often doesn't care *how* things are done -they just want to use the tools to meet their personal or business objectives. By objectives I mean getting connected to the Internet, or running in a GUI environment, or being able to create correspondences, etc. We may find that we need to extend the definition of Package as seen by Debian to allow for this. Several packages need files/devices in /dev, several add/change environment variables, some add services that are controlled by inetd, others provided services that are run-level specific, and the list goes no... To date, the only way we have of consistently applying these requirements is at a file level of granularity - maybe that's not appropriate. Perhaps we need to look at a consistent way for packages to indicate to Debian what services (for lack of a better word) are needed. Examples of my rantings: Instead of packages running mknod to create entries in /dev, have them tell update-mkdev (a utility I'm working on) to add entries to the files /etc/{devinfo,makedev.cfg} and then call makedev. Instead of packages creating the links and files for the various run-levels, or even requiring the packages to manipulate the run-level information with calls to update-rc.d, have the package instruct a utility to edit *one* file in /etc and then call update-rc.d to implement those changes. (Come to think about it, this is exactly the sort of thing that is done with /etc/inittab - and for the same reasons - we edit one file, with or without the help of an additional utility, and then call a program to implement those changes (ie. telinit -q) The same can be said about how Unix'es handle /etc/crontab - edit *one* file then (optionally) run a utility to implement those changes (ie. the crontab command)) The same could be done with the Environment variables (also a project I'm working on, and about to propose to debian-devel). Yes, this does add a level of indirection. Yes, this does start doing things differently than they have been traditionally done. Yes, there are some trade-offs involved. However, they may also allow for simpler administration, and easier configuration. These benefits can outweigh the negative issues. Chuck -- Chuck Stickelman, Owner E-Mail: <[EMAIL PROTECTED]> Practical Network Design Voice: (419) 529-3841 9 Chambers Road FAX: (419) 529-3625 Mansfield, OH 44906-1302 USA -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .