Luke Mewburn wrote:
# (*) Note to the peanut gallery; I'm sure a few vocal non-rc.d liking
# users might take this as an opportunity to start rubbishing rc.d
# again.  Please don't bother; we've heard it all before,

Then LISTEN, damn it!  We don't write this stuff to see our phosphors
glow for the hell of it!  We have some strenuous objections to #3, at
least.

For what it's worth, #1, #2, #4 and #5 make sense.  #3 is going to be
the most contentious issue of the bunch.

Look, the work you're trying to do here is commendable - I give you an
A+ on the effort side, but there are ways to make this work which
WON'T offend the sensibilities of the users who DO know what they're
doing (and, by the way, if the users aren't WILLING to learn about
what they're doing, WHAT THE HELL ARE THEY DOING RUNNING A SYSTEM!?).

Okay, sorry, I'll back off a bit.

#undef RABID_SYSADMIN	/* Sorry... */

# and I'll delete
# any such messages without replying EVEN if there's a possibility of a
# sane idea in the message.

Shooting off your own foot again?

# I.e, if you want to constructively contribute
# to the discussion, please do.  Otherwise please keep your `reply'
# trigger finger idle for a while...

I'm not here to "rubbish it" as you put it, but I think the suggestions
I've made ought to be taken seriously.

I'll sum it up:  rc.conf.d IS OKAY, but I want to be able to run my stuff
from rc.conf without my system whinging about it.  That's an extreme.
The other alternative is to allow rc.conf.d vars to override rc.conf
vars, or vice versa, depending on preference.  This is not as fraught
with error-prone-ness as you seem to think.  The automatons could toss
their own stuff into rc.conf.d, and at boot-up you get a warning saying
that there is something that should be in rc.conf but isn't.

Luke may now delete this message :-)

# Date: Mon, 01 May 2000 23:36:52 +1000
# From: Luke Mewburn <lukem@cs.rmit.edu.au>
# To: tech-userlevel@netbsd.org
# Subject: Proposed rc.d changes....
# 
# 	3. Reworking the configuration mechanism (replacing rc.conf)
# 
# 3. Reworking the configuration mechanism (replacing rc.conf)
# 
# 	Be warned; this is a contentious issue!

Do ya think? :_)

# 	After many discussions with a variety of people, it appears
# 	that the configuration mechanism for rc.d should have the
# 	following attributes:
# 		* simple/stable
# 		* easy to manage by a user
# 		* easy to manage by system/automated scripts
# 		* easy to upgrade
# 
# 	Whilst rc.conf is easy to manage by a user, it's not trivial
# 	to safely update it mechanically, nor is it easy to upgrade.
# 
# 	My proposal is to replace rc.conf with separate
# 	/etc/rc.conf.d/foo config files, one for each service, with
# 	contents similar to:
# 		foo=NO
# 		foo_flags="-q ex0 -p 667"
# 
# 	The primary concern with such an approach (and it's one I've
# 	had) is that it's not as easy for a user to manage multiple
# 	services at once (or setup a system from scracth).  If a tool
# 	is provided (e.g, virc(8))

Um, "no".

The *last* thing we need is another specialized vi-something tool.
vipw has its uses.  Someone was silly enough to create a vigr to
edit the group file.  This is a solution looking for a problem,
since /etc/group doesn't get changed in the middle of an edit by someone
trying to change a password.  virc would be an abomination.
You may consider this a strenuous objection on the grounds that it
is _so_ much easier to go through and edit a single conf than a bunch
of little ones in the first place.  virc would be, as someone once
applied to my own code/fixes, "an egregious hack".

# 	which presents /etc/rc.conf.d/* as
# 	a single editor buffer, which then rewrites /etc/rc.conf.d as
# 	necessary once the editor is successfully exitted, then I
# 	believe that this concern will be addressed.

I've suggested before, I'll suggest again, that we use rc.conf
as is, with something in it to either prefer the variable set in
rc.conf or the variable set in the individual config, in either case
printing a warning should the two disagree.

# 	From an implementation point of view, another rc.subr function
# 	- load_rc_conf() - would be used to load this config file.
# 	Thus, if someone *really* wants to retain rc.conf in their
# 	setup it's trivial for them to edit /etc/rc.subr and modify
# 	a single function to change how config files are sourced.

We are severely over-enhancing this particular piece of the startup.
The rc.d based startup is already slower coming up -- something I find
quite disturbing.  The last thing we need is something going out and
slowing down even more.

# 	Others have suggested very configurable configuration
# 	mechanisms [excuse the wording ;], but I feel that such
# 	proposals would result in making a system that was *too*
# 	configurable and harder for us (as a project) to support
# 	users. Having rc.d configuration information potentially
# 	coming from three sources (the rc.d/foo script, rc.conf or
# 	rc.conf.d/foo),

The configuration should not be in the script.  The configuration
should be either in rc.conf or a separate config file.

#	with different variations on which source
# 	takes priority, sets off `difficult to support' alarm bells.

"As a project."  You seem to be forgetting that this "project" would
not be here if it were not for the user base that has thus far supported
it.  Are you about ready to tell us all to go get fscked yet again?

The dual-edged mode would NOT be that hard to support, as the mechanism
by which value is to be selected would just already be there.

# 	We chose to support only one rc.d mechanism (as opposed to
# 	rc.d, /etc/rc, and SYSV init.d) for similar reasons; stick with
# 	one method, but make it easy for an individual site to
# 	consciously modify scripts if other behaviour is required.

I wanna bitch about rc.d, but I _can't_ (apart from its slowness and
ugly aesthetics).  The ability to kill a daemon without having to grep
its pid is actually a nicety.

For anyone who's interested, I have patches available (or will shortly)
to make the output look a bit more familiar WRT the RPC, NFS, networking
and system daemon set.  It's ugly, though -- took a lot of hackery to
get working right.  But the output looks more friendly at boot time.

# 	With load_rc_conf(), a site which wants to retain /etc/rc.conf
# 	semantics could do something like:
# 		- edit rc.subr to source rc.conf as well as the per
# 		  program configs
# 		- append /etc/rc.conf.d/* >> rc.conf
# 		- rm /etc/rc.conf.d/*
# 	and then be responsible for maintaining their configuration
# 	`in sync' with any future system or package tools.

This means that rc.conf/rc.subr needs to be quite aware that there is
no rc.conf.d and shut the hell up about it.

Angry?  Bitter?  Why, no.  Just because there's no consensus on this
and it looks like we're about to get steamrolled again...

# 


				--*greywolf;
--
BSD: Agnostics in the Platform Religious Wars.