From owner-svn-src-all@FreeBSD.ORG Thu Oct 2 04:59:28 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31CB6B23; Thu, 2 Oct 2014 04:59:28 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3D71E8; Thu, 2 Oct 2014 04:59:28 +0000 (UTC) Received: from [64.201.244.132] (port=59586 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XZSka-000049-3F; Wed, 01 Oct 2014 15:52:00 -0700 From: To: "'Hiroki Sato'" , References: <201410020116.s921GVTZ033933@svn.freebsd.org> <542CAABB.5090900@freebsd.org> <20141002.123747.2156790647982484029.hrs@allbsd.org> In-Reply-To: <20141002.123747.2156790647982484029.hrs@allbsd.org> Subject: RE: svn commit: r272393 - head/etc Date: Wed, 1 Oct 2014 21:59:11 -0700 Message-ID: <193c01cfddfd$9b1c6ef0$d1554cd0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIKWLejTHnCEajZOhjMlj6r7bWH2AH0PTEWApew9nObgumf0A== Content-Language: en-us Sender: devin@shxd.cx Cc: svn-src-head@freebsd.org, dteske@FreeBSD.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 04:59:28 -0000 > -----Original Message----- > From: owner-src-committers@freebsd.org [mailto:owner-src- > committers@freebsd.org] On Behalf Of Hiroki Sato > Sent: Wednesday, October 1, 2014 8:38 PM > To: cperciva@freebsd.org > Cc: src-committers@freebsd.org; svn-src-all@freebsd.org; svn-src- > head@freebsd.org > Subject: Re: svn commit: r272393 - head/etc > > Colin Percival 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. > 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