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?"