Subject: Re: Updating /etc...
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
From: Greg Hudson <ghudson@mit.edu>
List: current-users
Date: 12/19/1995 12:24:33
> /sbin/init.d/*	the scripts
> /etc/rc.d/*		symlinks to the scripts, with appropriate
> 			names so they'll get run right.

I have three arguments with this, two of them sort of the same:

	1. Why should packages need startup and shutdown scripts?
	   Maybe I'm being too idealistic here, but from my point of
	   view, every package should be able to start up by running a
	   single executable which refers to configuration files in
	   /etc to decide what to do.

	   Perhaps that "single executable" can be a script, but I
	   don't see any reason why it should always be a script and
	   why it should be located in /sbin/init.d instead of in a
	   normal binary directory.  Especially for small packages
	   which are only composed of one program, the program itself
	   should be able to function as the entry point to the
	   package.

	   (You made an argument about this point in your message, but
	   you trailed off at "but i think it'd be silly to do
	   so. consider the 'init' scripts just like a part of the")

	2. From a file-hierarchy point of view, subdirectories of
	   binary directories make me wary.

	3. Even if the world worked in the way I dreamed about in (1),
	   we'd still need to decide what order to start up packages.
	   Symlinks in /etc/rc.d is one way to do that, but I don't
	   see how symlinks in a directory is at all superior to a
	   file listing the executables to run and in which order
	   (possibly with annotations for runlevel requirements and
	   anything other kind of flexibility you want to add).

	   Perhaps it's that, during an upgrade, you can merge the
	   symlinks from the system in with your symlinks and still
	   have everything take place in pretty much the same order?
	   I don't think numbered symlinks gives you any such
	   guarantee, and I think you can do just as good a job
	   merging in a file as a directory.

The /etc/rc.d and <something>/init.d approach may be an improvement
over /etc/rc--certainly, encoding part of a package's configuration
information inside the middle of a system startup file is a complete
lose--and you might even convince me that in a world of packages which
don't behave very well, /etc/rc.d and /etc/init.d is the best
compromise solution.  But I still won't like it.