> S000inet       S05settime     S24afs         S46timed       S77httpd
> S001route      S08startlmf    S25preserve    S49snmpd       S80crashdc
> S002inet_usr   S10syslog      S26security    S55inetd       S90postgres
> S003savecore   S11gateway     S27sia         S57cron        S93kerberos
> S004paging     S13rwho        S30rmtmpfiles  S60motd        S94mmeserver
> S005recpasswd  S15named       S36presto      S61clcdev.mc   S95xdm
> S006enlogin    S18nis         S37atm_otto    S63write
> S006streams    S19nfs         S39amd         S65mdqs
> S01quota       S20nfsmount    S40sendmail    S67bootpd
> S04uucp        S21audit       S45xntpd       S75acct

> You can see that this sets up net services, sets up the static routes,
> mounts a remote /usr, checks for crash dumps, sets up paging, something
> with the passwd file  (actually is a recover from a crash in the midst of a
> vipw), etc, etc.  This isn't much difficult than groping through the rc
> files, and probably easier.  (at least imho).

This isn't anywhere near as obvious as you say.   Yes, the meanings of
some of the names are evident even to me, but the meanings of a lot of
them aren't.

What I would like to see is a set of config files stored in
/etc/config, which are provided by various packages, both those
provided with the system (e.g., named and gated) and those provided by
vendors (e.g., oracle).  Each of these files would contain a very
brief (one-line) title, a less brief description of what functionality
it provides, a machine-readable list of prerequisites before the
package can be started, a machine-readable list of features the
package provides, a version number, and a machine-readable list of
parameters that the systadmin must control in order to enable the
package.   More than one package might provide the same overall
functionality - e.g., gated and routed both provide ``routing''
although gated does a more complicated job of it.   A script to set up
a static route would also provide ``routing.''

A registry of feature names would be required - we don't want one
package to provide ``routing'', while another package provides
``routes''.  In addition to package documentation, registered features
would also have documentation describing the overall goal that the
feature achieves.  The documentation for each package would need to
provide enough information to allow a relatively (but not completely)
naive admin to choose between them - there are obvious reasons to use
gated, routed or static routes which aren't all that hard to explain.

When the system is initially configured, the sysadmin can be presented
with a list of available features, a description of what each does,
and a list of the packages that provide them.   When the sysadmin
chooses a particular feature and a particular package, s/he would then
be prompted for any information that package requires in order to
start.

This same process would be repeated when installing a new package off
of a tape or CD.

The user-provided information would be stored in one file,
/etc/localconfig.   Along with the information for each package, a
version number would be stored, so that packages could automatically
convert information for old versions into a new format during an
upgrade.

Whenever a change is made to /etc/localconfig, a program called
/usr/sbin/genrc is run to generate a new /etc/rc.  This /etc/rc is
completely machine generated, but contains the config-file blurb for
each package it invokes, comments indicating where each instruction in
it comes from, and a caveat at the top to the effect that the file is
automatically generated, and that changes made to it should not be
expected to persist.  genrc uses the features provided and required by
each package's configuration files to determine in what order the
startup and shutdown programs should be executed.   /etc/localconfig
contains a list of feature requirements sort of like the first
dependency line in a makefile - only packages providing features
listed in /etc/localconfig and packages providing features required by
other required packages are listed in /etc/rc.   An /etc/cr (pick a
name, any name) contains a list of commands to execute on shutdown,
documented as in /etc/rc.

This puts all the information that you need to understand how a system
starts up and shuts down in a well-known place, along with sufficient
documentation to figure out how it got there.   You can't put comments
on filenames, at least not in Unix, but you can comment files, and I
think this makes them a better choice.

Anyway, I feel that this system provides a substantial improvement
over /etc/rc without resulting the level of obscurity that I (and
apparently many others) associated with /etc/init.d.   Unfortunately,
it's also a lot of work.

			       _MelloN_