Well, what a contentious issue!  People seem to be confusing a problem
with the implementation with which system NetBSD ships with.

I see the following options for implementation. We should choose one
of these, and possibly ship with the ability for a user to switch to
another if they so desire.

a)	Do nothing
	Pros:
		- nochangeniks like it
	Cons:
		- hard to control daemons post boot (without examining
		  /etc/rc to see how something was started)
		- difficult for third parties to add scripts

b)	/etc/rc is autogenerated from /etc/init.d at some stage
	(possibly by the developer who last changed an init.d
	script).
	Pros:
		- works almost the way things do now, as well as
		  allowing manual control over daemons with
		  /etc/init.d/foo
	Cons:
		- still not easy for thirdparty scripts, unless
		  they follow the same convention that our scripts
		  do (supporting dumpstart, etc...)
		- have to regen /etc/rc if a change occurs in
		  /etc/init.d

c)	/etc/rc runs rcorder over /etc/init.d and runs scripts
	as necessary. (rc.sh and rc.shutdown.sh implements this)
	Pros:
		- thirdparty scripts (that support `start' and `stop'
		  work) with minor changes (need to add `PROVIDE:'
		  and `REQUIRE:' lines if ordering is necessary)
	Cons:
		- slower that b)
		- still needs minor changes to 3rdparty scripts
		  (you need to add the PROVIDE/REQUIRE lines)

d)	/etc/rc runs /etc/rc3.d/S* in filename order.  (rc.sysv.sh
	implements this). /etc/rc3.d is created from /etc/init.d by
	running `mkrc -s01` once.
	Pros:
		- ordering is obvious
		- allows people to install their own scripts in a
		  given order
	Cons:
		- considered to be an ugly warty sysvism by a lot of
		  people
		- if 3rdparty scripts are to be integrated into the
		  mkrc phase they need PROVIDE/REQUIRE lines.
		- not a true SYSV setup (no inittab/runlevels)

e)	/etc/rc is autogenerated from /etc/init.d/ containing a list of
	lines which just do "/etc/init.d/foo start; /etc/init.d/foo2 start",
	etc.
	Pros:
		- ordering is obvious in script (doesn't depend upon
		  rcordering at boot time)
	Cons:
		- have to regen /etc/rc if /etc/init.d is updated.

f)	Full SYSV style run levels.
	Pros:
		- don't know
	Cons:
		- does it really win us anything.
		- This is BSD.

[There's probably other options I've missed as well.]

The questions are:

	1. Which method do we ship with enabled by default?
		I'd argue for b) or c), possibly supporting d) or e),
		and strongly against f).

	2. Do we support the other methods (e.g sample scripts in
	   /usr/share/samples/rc/) such as rc.sysv.sh if we choose
	   rc.sh.
		I'd say `yes', because there's no real harm in
		giving people the choice.

Fight it out, people...

(Followups to the list only please; I get a copy anyway...)