From owner-freebsd-rc@FreeBSD.ORG Mon Jan 9 13:43:38 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFCD106567F; Mon, 9 Jan 2012 13:43:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id D59008FC24; Mon, 9 Jan 2012 13:43:36 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q09DhNjL057604; Mon, 9 Jan 2012 22:43:33 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q09DhLFE095964; Mon, 9 Jan 2012 22:43:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 09 Jan 2012 22:35:10 +0900 (JST) Message-Id: <20120109.223510.1979757999064039809.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F0A22D8.8090206@FreeBSD.org> <4F0ABE04.5050503@FreeBSD.org> References: <4F08C95F.6040808@FreeBSD.org> <20120108.081216.1547061187942402256.hrs@allbsd.org> <4F0A22D8.8090206@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Jan__9_22_35_10_2012_563)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 09 Jan 2012 22:43:33 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-rc@FreeBSD.org Subject: Re: Making use of set_rcvar. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 13:43:38 -0000 ----Security_Multipart(Mon_Jan__9_22_35_10_2012_563)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F0A22D8.8090206@FreeBSD.org>: do> On 01/07/2012 15:12, Hiroki Sato wrote: do> > I am always wondering if defining $rcvar as "${name}_enable" at the do> > end of load_rc_config() when $rcvar is undefined is bad idea. do> > do> > Is there any problem with removing rcvar=... in individual rc.d do> > scripts except for non-standard ones (empty or different from do> > ${name}_enable)? It looks simpler than writing the same line do> > "rcvar=${name}_enable" many times in various places. do> do> This sounds like a great idea in theory, but in practice it doesn't work do> out, for 2 reasons. First, we have a lot of scripts in the base (about do> 1/3) that rely on the lack of any rcvar meaning that it gets run do> unconditionally. In order to provide backwards compatibility we'd have do> to add code to enable things by default that were previously unset. do> That's not hard to do, but .... do> do> The other reason is that for ports, the scripts generally look like this: do> do> load_rc_config foo do> do> : ${foo_enable:=NO} do> do> See the problem? Removing rcvar=`set_rcvar`, and then adding rcvar="" into scripts that need to be run unconditionally would work. However, I have no strong opinion about that. I agree that it needs some more code anyway and keeping things simple is better. Doug Barton wrote in <4F0ABE04.5050503@FreeBSD.org>: do> > The use of "${name}_enable" does not add measurable overhead, but that do> > way more of an existing script might be used as a prototype unchanged. do> do> I understand what you're saying, and I know that the whole "use do> variables wherever we can" thing is all '1337 and computer science'y, do> but it's silly. The concept of a universal template that can be copied do> and pasted for different services is a pipe dream. There are already do> many things that need to be changed in the new script, and not updating do> rcvar for a new script causes clear and obvious failure messages. I prefer to use ${name}_enable because putting the same keyword in two places always leads to a stupid typo issue. -- Hiroki ----Security_Multipart(Mon_Jan__9_22_35_10_2012_563)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8K7Q4ACgkQTyzT2CeTzy2MFwCg2GXL8vB04QFHfJ5uqw6x+V54 WuAAnAwz8bq5n5eY5JI2luYPr1TF6t+Q =C6H7 -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Jan__9_22_35_10_2012_563)----