From owner-svn-src-head@FreeBSD.ORG Thu Oct 2 03:39:31 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BBFDF26; Thu, 2 Oct 2014 03:39:31 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5007BACC; Thu, 2 Oct 2014 03:39:30 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s923d4ma051923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Oct 2014 12:39:15 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s923d1h5015132; Thu, 2 Oct 2014 12:39:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 02 Oct 2014 12:37:47 +0900 (JST) Message-Id: <20141002.123747.2156790647982484029.hrs@allbsd.org> To: cperciva@freebsd.org Subject: Re: svn commit: r272393 - head/etc From: Hiroki Sato In-Reply-To: <542CAABB.5090900@freebsd.org> References: <201410020116.s921GVTZ033933@svn.freebsd.org> <542CAABB.5090900@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Oct__2_12_37_47_2014_642)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 02 Oct 2014 12:39:24 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:39:31 -0000 ----Security_Multipart(Thu_Oct__2_12_37_47_2014_642)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. -- Hiroki ----Security_Multipart(Thu_Oct__2_12_37_47_2014_642)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQsyIsACgkQTyzT2CeTzy3ZdwCfQh1CkzJMQ76OfJ4xbHEaNoY+ f10An0h6thcsnu9IOdidwWkrXYB2SpAP =NkWt -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Oct__2_12_37_47_2014_642)----