From owner-freebsd-rc@FreeBSD.ORG Mon Jan 9 16:17:37 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 982BE106564A; Mon, 9 Jan 2012 16:17:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 407328FC13; Mon, 9 Jan 2012 16:17:36 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so5906026obb.13 for ; Mon, 09 Jan 2012 08:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=RYXbg5GNv3gTD5BzuoZd2U5txWuq4pVeAiURpIIikik=; b=cHIAkQC6pQHB/+3NQc1lbYysyFdokXJQdWe/vzPaWoinZ893WVA/hKupEF+B+9bq5v wEnSRMeTFi0qHfYxbNtyQEI6PQcFQhT+uBU7qLjocQa1REH0oAFm5Ze/9CXq4ZkfQtY+ Si9gv3Wc2uhnh/1M1FotTuFscymdN/j/va3Ro= Received: by 10.182.109.106 with SMTP id hr10mr15287759obb.27.1326125856601; Mon, 09 Jan 2012 08:17:36 -0800 (PST) Received: from [192.168.20.12] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id g9sm4184680obm.0.2012.01.09.08.17.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 08:17:35 -0800 (PST) References: <4F08C95F.6040808@FreeBSD.org> <20120108.081216.1547061187942402256.hrs@allbsd.org> <4F0A22D8.8090206@FreeBSD.org> <20120109.223510.1979757999064039809.hrs@allbsd.org> In-Reply-To: <20120109.223510.1979757999064039809.hrs@allbsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Mon, 9 Jan 2012 08:17:30 -0800 To: Hiroki Sato 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 16:17:37 -0000 On Jan 9, 2012, at 5:35 AM, Hiroki Sato wrote: > Doug Barton wrote > in <4F0A22D8.8090206@FreeBSD.org>: >=20 > 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=3D... 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=3D${name}_enable" many times in various places. > do> > do> This sounds like a great idea in theory, but in practice it doesn't wo= rk > 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 th= is: > do> > do> load_rc_config foo > do> > do> : ${foo_enable:=3DNO} > do> > do> See the problem? >=20 > Removing rcvar=3D`set_rcvar`, and then adding rcvar=3D"" 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. >=20 > Doug Barton wrote > in <4F0ABE04.5050503@FreeBSD.org>: >=20 > do> > The use of "${name}_enable" does not add measurable overhead, but th= at > do> > way more of an existing script might be used as a prototype unchange= d. > 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 updatin= g > do> rcvar for a new script causes clear and obvious failure messages. >=20 > I prefer to use ${name}_enable because putting the same keyword in > two places always leads to a stupid typo issue. +1 Thanks, -Garrett=