Subject: Re: The new rc.d stuff...
To: Luke Mewburn <lukem@cs.rmit.edu.au>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: current-users
Date: 03/30/2000 11:29:47
On Thu, Mar 30, 2000 at 07:15:28PM +1000, Luke Mewburn wrote:
> Robert Elz writes:
> >   | then the flags in the file override /etc/rc.conf
> > 
> > Which has what purpose left exactly?   To define rc_configured ?
> 
> PATH, RC_PATH (if we go that route), rc_configured (if we keep that),
> and other `global' type stuff.
> 
> I'm compiling up a proposal covering these ideas on replacing rc.conf.
> 
> NOTE: at the time I put rc.d in I knew that rc.conf needed work. However,
> I figured it was easier to break up the work into chunks:
> 	* ability to start/stop individual daemons/programs/processes,
> 	  and control the ordering using rcorder.
> 	* allow for (automatic) addition/removal of third party
> 	  scripts, including taking into account the potential namespace
> 	  conflict issues
> 	* enhancing the configuration mechanism (rc.conf) to support
> 	  the point above.
> The first has been done. It's time to solve the last two points.

I don't think some of this needs "solving".  I think in one key way the
current "solution" sucks, if it proceeds in the way it looks to be going.

With rc.conf, and the old mechanism, I could completely configure a system
from a bare prototype by editing *one* file.  (Well, two, actually, because
of resolv.conf, but that's a minor nit).

If you move all the configuration information out of that file, I have
a *lot* more work to do to see what makes one system different from another.
I really don't like the idea of having to grovel through 15 different files,
either when configuraing or debugging, *at all*.

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
	"And where do all these highways go, now that we are free?"