On Dec 2, 11:03am, Luke Mewburn wrote:
} 
} 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

     I wouldn't call myself a "nochangenik", but I don't like change
just for the sake of change.  If something changes there must be a
demonstratable benefit.

} 	Cons:
} 		- hard to control daemons post boot (without examining
} 		  /etc/rc to see how something was started)

     I don't find this to be a problem, but then I've been admin'ing
UNIX for 10 years (more if you count my days with Minix), so I have all
the options memorised anyways.  However, I do see how this could be a
problem for newbies.

} b)	/etc/rc is autogenerated from /etc/init.d at some stage
} 	(possibly by the developer who last changed an init.d
} 	script).

     If we have to change, this is the option that I prefer, combined
with some method of handling "standard" thirdparty scripts.

} 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.
} 	Cons:
} 		- considered to be an ugly warty sysvism by a lot of
} 		  people

     Yep.

} 		- if 3rdparty scripts are to be integrated into the
} 		  mkrc phase they need PROVIDE/REQUIRE lines.

     I don't think this is particularly onery since they already have
to worry about whether the system uses two digits or three digits,
where the directories are (on HP-UX they are in /sbin), and what the
default run level is.

} 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.
} 	Cons:
} 		- have to regen /etc/rc if /etc/init.d is updated.

     Add, very slow.

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

     Yep.  If NetBSD starts down this path, then I (and probably
others) will be looking at switching OS'es.  One of the big reasons
that I use NetBSD is precisely because it is BSD.  rc.conf is a nice
improvement over the standard rc since it makes it easy to turn things
on and off and configuration is centralised (one of the things I really
hate about SysV is how configuration information is spread all over the
place).  Going to that really ugly SysV method would be a major step
backwards.  For those that want SysV, they know where to find it.

} [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).

     See above.

} 	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.

     I don't really see the point in this since it could lead to
problems with support (both internal to organisations due to differnt
admins doing things different ways, and external), but I don't have any
really strong objections to it.

}-- End of excerpt from Luke Mewburn