On Fri, 3 Dec 1999, Greg A. Woods wrote:

: NetBSD really must support SysV-style "start/stop" scripts -- it's the
: only sane way to control stuff installed by packages.

I looked back at my sidelong proposal from another thread, and came up with
yet another idea.

If we want "run_rc_command" for shipped tools, fine.  Let it parse
start/stop/whatever and DTRT.

Other scripts can manually parse for start/stop/whatever.  This way, vendor
scripts can be dropped in without modification.

Scripts do not have PROVIDES.  The provided service is the name of the
script.  No script provides more than one service.

We have a dependency configuration file, /etc/rcdeps (named this only for
the sake of example), where provides/requires info is added for the sake of
scripts added by the user, and an admin could define arbitrary runlevels and
dependencies:

singleuser: runlevel1
multiuser: runlevel3
#
runlevel1: mount_local
runlevel2: runlevel1 networking mount_nfs
runlevel3: runlevel2 inetd httpd sshd
#
networking: dhclient
httpd: pgsql

Note that it looks pretty stripped-down here--that's because I still assume
that system scripts will have the minimal, needed, REQUIRES as text data in
the script itself.  Here, I defined three runlevels, an extra dependency for
networking support, and the extra services for httpd (and its dependency,
pgsql).

There would be an explicit list of "major components" used to define by the
admin what singleuser, multiuser, runlevelN consist of; then a list of
"optional components" that the admin may add as dependencies, such as
mount_nfs and dhclient above.

Opinion...?

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