svn commit: r272393 - head/etc

[dteske at FreeBSD.org]

> -----Original Message-----
> From: owner-src-committers at freebsd.org [mailto:owner-src-
> committers at freebsd.org] On Behalf Of Hiroki Sato
> Sent: Wednesday, October 1, 2014 8:38 PM
> To: cperciva at freebsd.org
> Cc: src-committers at freebsd.org; svn-src-all at freebsd.org; svn-src-
> head at freebsd.org
> Subject: Re: svn commit: r272393 - head/etc
> 
> Colin Percival <cperciva at freebsd.org> wrote
>   in <542CAABB.5090900 at freebsd.org>:
> 
> cp> On 10/01/14 18:16, Hiroki Sato wrote:
> cp> >   This is an attempt to solve a problem that rc.d scripts from
third-party
> cp> >   software do not have entries in /etc/defaults/rc.conf.
> cp>
> cp> Isn't this why we have the
> cp> > : ${foo_enable="NO"}
> cp> idiom in ports rc.d files?
> cp>
> cp> >   The fact that
> cp> >   load_rc_config() reads rc.conf only once and /etc/rc invokes the
> function
> cp> >   before running rc.d scripts made developers confused for a long
time
> because
> cp> >   load_rc_config() just before run_rc_command() in each rc.d script
> overrides
> cp> >   variables only when the script is directly invoked, not from
/etc/rc.
> cp>
> cp> If a script is setting variables for its own use, there's no need to
use
> cp> functions from rc.subr -- it can just set the variables directly.  If
a
> cp> script is editing rc.conf, sending a SIGALRM to $$ will signal /etc/rc
to
> cp> re-source rc.conf.
> cp>
> cp> I'm really not clear on what this commit accomplishes.
> 
>  The primary purpose is to make it clear which variables are used in
>  the script for *user configuration* and provide a consistent writing
>  style for scripts from both base and ports.  More specifically, I
>  want to implement a way to list user-configurable variables and which
>  one is changed from the default value, by effectively replacing
>  functionality of defaults/rc.conf with set_rcvar().
> 
>  Use of : ${foo="NO"} idiom after load_rc_config() works as you
>  pointed out.  However, it does not work with listing variables.
>  Plus, there are many scripts written in an inconsistent way.  Some
>  scripts call load_rc_config() multiple times, some have the idioms
>  between load_rc_config() and run_rc_command(), and some have them
>  mistakenly before load_rc_config().  I think this is due to confusion
>  about how load_rc_config() works and all of them can be
>  fixed/rewritten consistently of course, but I think gathering
>  definitions at the head of the scripts and making them being defined
>  at the end of load_rc_config() as set_rcvar_obsolete() does are more
>  intuitive.
> 

I'm going to chime in here. I'm equally befuddled because
for years (properly understanding load_rc_config()) would
just create a file under /etc/rc.conf.d/.

There's your stand-in for /etc/defaults/rc.conf right there;
a file in the little-known and even less talked-about
/etc/rc.conf.d/ directory -- where I believe you it is that
one precisely does what it is you're looking for (based on
your description).
-- 
Devin