Subject: Re: Possible design of the new rc.d rc.conf stuff.
To: None <firstname.lastname@example.org>
From: None <email@example.com>
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 firstname.lastname@example.org 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.