Subject: Re: Possible design of the new rc.d rc.conf stuff.
To: None <>
From: None <>
List: current-users
Date: 04/18/2000 01:03:27
On Mon, Apr 17, 2000 at 05:55:29PM -0700, Paul Goyette wrote:
> On Mon, 17 Apr 2000 wrote:
> > [rc.d rc.conf proposal and conf_dir_preferred variable]
> I think I don't like the name or sense of the variable!  :)
> If I _prefer_ the /etc/rc.config/* stuff, then it should be sourced
> _after_ the /etc/rc.conf file, so that it's values can override and
> therefore be preferred.  With the variable name and sense the way you've
> written it, I should set conf_dir_preferred=YES to prefer the values set
> in /etc/rc.d - this seems backwards!
> So, either change the name of the variable (maybe to something like
> monolithic_conf_preferred) or change the sense of YES and NO.
	er, yeah.  I changed the name of that variable a couple times
so the meaning got a little confused. :)  Also the rc.d/foo script should
have the uncommented default values (i.e. "foo=NO") before rc.subr.
	With conf_dir_preferred I meant the /etc/rc.config directory.  I guess
there's a bit of confusion possible there.  On the other hand I didn't
want the variable to be monolithic_conf_preferred because I was thinking
that not having it set should default to preferring the monolithic conf file.
If anyone can think of a less potentially confusing name than conf_dir_pref...
I say go with that.  However, since someone who doesn't have the variable
(whatever it is named) set likely won't have anything in their rc.config
directory, it won't matter.
	I guess the point here is that the important thing here seems to
make the name of the variable as clear as possible.  Since I can't think
of something better monolithic_conf_preferred sounds good to me.

> > 	So what problems does anyone see with this?
> Someone earlier in this thread suggested that it would be useful to have
> some kind of warning if a variable were defined in both the /etc/rc.conf
> and /etc/rc.config/* files.  I think that that would be useful, too, but
> I admit I can't see any easy way to implement it.
	:) That's why I didn't mention it.