Colin Percival <cperc...@freebsd.org> wrote in <542caabb.5090...@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.
-- Hiroki
pgpvpkfG2QEpj.pgp
Description: PGP signature
