Date: Thu, 02 Oct 2014 12:37:47 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: cperciva@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r272393 - head/etc Message-ID: <20141002.123747.2156790647982484029.hrs@allbsd.org> In-Reply-To: <542CAABB.5090900@freebsd.org> References: <201410020116.s921GVTZ033933@svn.freebsd.org> <542CAABB.5090900@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Colin Percival <cperciva@freebsd.org> wrote
in <542CAABB.5090900@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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlQsyIsACgkQTyzT2CeTzy3ZdwCfQh1CkzJMQ76OfJ4xbHEaNoY+
f10An0h6thcsnu9IOdidwWkrXYB2SpAP
=NkWt
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141002.123747.2156790647982484029.hrs>