Re: /etc/init.d structure [even longer rant]
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: <stick@richnet.net>
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
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: