> Date: Tue, 19 Dec 1995 14:02:24 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> 
> Some (possibly controversial) comments:
> 
> 1) I think that everyone agrees that it would be better if packages
>    could just drop an initialization file into the "right place" and
>    have the "right thing" happen -- i.e. that the notion of an rc.d
>    isn't so bad, but that it doesn't by itself solve some problems.
> 2) I think that people generally agree that run levels aren't
>    something we want in NetBSD.
> 3) I think that people generally agree that people want flexibility,
>    so it is better if the rc.d style thing gets invoked by rc via a
>    shell mechanism and is not built in to init -- ditto that people
>    aren't really in to shutdown scripts.

That would allow those of the dyed-in-the-wool BSD faith to just nuke
any blasphemous directory stuff and use an rc+rc.local (hi mouse 8^)

> 4) I think that people generally agree that we need a better mechanism
>    to solve the ordering problem for scripts -- you really want to be
>    able to say "start this thing after dns and nfs are up", etc.
> 
> 4) Is the only problem that I think is hard, and I believe that by
> having an explicit dependency list in each script file, we can
> probably have some code produce an ordering based on dependencies
> rather than trying to do this by kludges like putting numbers in front
> of the scripts.
> 
> Comments?

Much noise is made about the ordering problem, but as a practical
matter, I've never seen any really complicated dependency graphs
in system startups.  In most cases, one could probably just divide
the startup into a small number of phases and leave it at that.

If one used that approach, how many phases would be needed?
How many of them might actually need actions added?

	Before root is remounted read/write
	Before /usr (and others) are mounted
	Before switch to secure mode (load drivers?)
	Before network is started up
	After network is started up
	After network daemons are up
	... (others?)