From owner-freebsd-rc@FreeBSD.ORG Mon Jan 9 17:12:13 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 85E711065670; Mon, 9 Jan 2012 17:12:13 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3268FC15; Mon, 9 Jan 2012 17:12:12 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa05 [127.0.0.1]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with SMTP id q09GfdPL010340; Mon, 9 Jan 2012 11:12:11 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com with ESMTP id 1283yk84ar-12 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 Jan 2012 11:12:11 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jan 2012 11:12:07 -0600 From: Devin Teske To: "'Garrett Cooper'" , "'Hiroki Sato'" References: <4F08C95F.6040808@FreeBSD.org> <20120108.081216.1547061187942402256.hrs@allbsd.org> <4F0A22D8.8090206@FreeBSD.org> <20120109.223510.1979757999064039809.hrs@allbsd.org> In-Reply-To: Date: Mon, 9 Jan 2012 09:12:07 -0800 Message-ID: <07de01cccef1$d2e73630$78b5a290$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQR4hqSCIYbzlOaK1Sfp0UW7jaygHdB8ZrApGUiKoBrkYqVwKW/xRxlje1QZA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2012-01-09_06:2012-01-09, 2012-01-09, 1970-01-01 signatures=0 Cc: dougb@FreeBSD.org, 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 17:12:13 -0000 > -----Original Message----- > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > On Behalf Of Garrett Cooper > Sent: Monday, January 09, 2012 8:18 AM > To: Hiroki Sato > Cc: dougb@FreeBSD.org; freebsd-rc@FreeBSD.org > Subject: Re: Making use of set_rcvar. > > On Jan 9, 2012, at 5:35 AM, Hiroki Sato wrote: > > > 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 > > do> > the 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 > > do> doesn't work out, for 2 reasons. First, we have a lot of scripts > > do> 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 > > do> have 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, > > do> > but that 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 > > do> science'y, but it's silly. The concept of a universal template > > do> that can be copied and pasted for different services is a pipe > > do> dream. There are already many things that need to be changed in > > do> the new script, and not updating 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. > > +1 > Thanks, > -Garrett +1 again. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.