On Thu, 2 Dec 1999, Luke Mewburn wrote:

: Vendor scripts would have to be modified to have the appropriate
: PROVIDE/REQUIRE/BEFORE lines if you wanted them to start at a
: particular point. If not, they will be started sometime at the end,
: with all the other scripts that are at the `end of the chain' (this
: is part of rcorder(8), and that program could be tweaked to change
: this behaviour).

I'd expect scripts to need to be modified--even if only adding a
"wrapper"--if they needed _any_ special start order other than "run sometime
after the rest of the OS has started up".  The 1.4 and earlier state of
affairs was no different.

: You'd have to give me a really good reason for arguing for the
: larger/messier version which doesn't use run_rc_command,
: especially since the run_rc_command version is easier to read/debug.

I don't really see what's stopping us from allowing a script to use
run_rc_command _or_ parse the arguments at the script author's choice.

On Thu, 2 Dec 1999, der Mouse wrote:

: > 5. The old /etc/rc style.  Dispense with it.  It's nothing but a
: >    speed hack, really,
: 
: Not at all.  It's also an immense boon to humans that have to have
: anything to do with the boot process.  I've used SysV-style split-apart
: boot scripts and I've used BSD-style monolithic boot scripts, and for
: human frobbing, the BSD style is far easier.

I used to be in the same opinion, but I've found that most human frobbing
involves reordering something or changing a hardcoded value (which should,
indeed, be made configurable).  With the proper granularity[*] and a
repository, or at least a human-readable index of repositories, of config
info, the goal of not having to frob anything can be attained.

[*] This means VERY modular scripts.  Typically, the speed lost by multiple
scripts can be regained by "source"'ing [". filename"] the scripts rather
than running them in subshells.  With that done, the modules could be as
granular as things like "mount_nfs_disks" or even "mount_usr_local" (a
user-created script, from a template, or even an internally parsed action
name).

What I don't remember seeing in many of the proposals is an easy way for a
user to add dependencies in cases where the scripts would otherwise be
executed in arbitrary order [without modifying a particular script].  I'd
venture a proposal to have such a configuration file, so that you could say:

mount_critical_fs: nfs_client mount_stand

and get your NFS partitions and /stand mounted before things that needed
system-important filesystems.

...Or maybe I've just had too much caffeine today....

-- 
-- Todd Vierling (tv@pobox.com)