> I like the rc.d/* as links to init.d/* approach; sometimes you need a
> way to turn off a package without deleting it entirely.
> 
> Here's a skeleton for a minimal way to do the automatic dependancy
> ordering..
> 
> for pkg in /sbin/rc.d/*
> do
> 	${pkg} startdeps
> done | tsort | while read pkg
> do
> 	/sbin/rc.d/${pkg} start
> done

it seems to me that the 'right' set of names here are:
	/sbin/init.d		'unchanging' startup/shutdown scripts.
				people can run scripts directly
				from here, and know that they're all
				here (no guessing).
	/etc/rc.d		links to files in /sbin/init.d, i.e.
				the contents of this directory
				is expected to change.

Also:

(1) Well, unless you move tsort to /, you've lost already...  i don't
particularly like the idea of moving tsort to / (more wasted space).

(2) i don't particularly like the idea of doing boot-time calculation
of dependencies & ordering (wasted time).  I'd prefer, say, a way for
people to force the ordering they want, perhaps in addition to
boot-time calculation.  (i'm willing to say if you hard code the
ordering and it's not a valid ordering, you've screwed yourself and
it's not our problem.)

(3) if you're going to do this, then do you mark started packages
anywyere?  If you're going to include dependencies, then what do you
do if (in your example) Joe Bob wants to start up named but hasn't
already started up 'net'?  You provide half of the mechanisms to
deal with that...  at the very least, a message should be printed
saying "you've gotta start net first," and you can't do that without
even more tools.

(4) would there be something analogous for shutdown time?  (if not,
why not?)  if so, how would it work?  ("named must be shut down before
net"?  certainly, that _could_ work, while "net must be shut down
after named" could not.  However, i wonder if even the former could
work in a sane way...)

(5) how does this deal with e.g. keeping the link in place, but just
moving it "out of the way" for a bit?  (e.g. with the SysV scheme,
you can move S.... to notnow.S..., and all will continue to work.
where is "out of the way" in this scheme?)

(6) what tools would be useful to help manipulate startup script
orderings?  i could see: print out order given config files/links in
this dir, sanity check orderability of config files/links in this dir
(it could be necessary to add an 'error out if cycle' option to tsort
for this purpose), and check given (forced) ordering for sanity.


I'm backing away from my previous position that ordering _must_ not be
done at boot time, but i'd like to know what proposed solutions for
the above-listed problems are...

Unless we pick an implementation similar to what somebody (SysV) has
already done, we run the risk of producing a novel system startup
scheme, and, well, unless there's a fair bit of benefit i'd say it's
not worth it.



chris