From owner-freebsd-rc@FreeBSD.ORG Sat Jan 7 23:12:32 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 58561106566C; Sat, 7 Jan 2012 23:12:32 +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 4EB228FC0C; Sat, 7 Jan 2012 23:12:31 +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 q07NCJlQ000955; Sun, 8 Jan 2012 08:12:29 +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 q07NCIXR075248; Sun, 8 Jan 2012 08:12:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 08 Jan 2012 08:12:16 +0900 (JST) Message-Id: <20120108.081216.1547061187942402256.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F08C95F.6040808@FreeBSD.org> References: <4F079A76.3030306@FreeBSD.org> <20120107112538.GC1696@garage.freebsd.pl> <4F08C95F.6040808@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(Sun_Jan__8_08_12_16_2012_123)--" 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]); Sun, 08 Jan 2012 08:12:29 +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, pjd@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: Sat, 07 Jan 2012 23:12:32 -0000 ----Security_Multipart(Sun_Jan__8_08_12_16_2012_123)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F08C95F.6040808@FreeBSD.org>: do> On 01/07/2012 03:25, Pawel Jakub Dawidek wrote: do> > On Fri, Jan 06, 2012 at 05:05:58PM -0800, Doug Barton wrote: do> >> On 01/06/2012 06:13, Pawel Jakub Dawidek wrote: do> >>> Any objections? do> >>> do> >>> http://people.freebsd.org/~pjd/patches/set_rcvar.patch do> >>> do> >>> This patch only changes scripts where set_rcvar can be used with no do> >>> arguments. do> >> do> >> Please don't do this. do> >> do> >> Jilles already pointed out the important reason, it adds pointless do> >> forks. I suggested a long time ago that we remove set_rcvar altogether do> >> but I got a lot of resistance to it, and never pursued it. Perhaps it's do> >> time to revisit that. do> > do> > It is a total mess now then and it is definiately not intuitive when do> > there are much more bad examples than good ones: do> do> I agree, which is why I previously proposed assigning them all directly do> when possible (which is in almost all cases). If no one speaks up do> opposing this idea in the next few days I'm still prepared to proceed. I am always wondering if defining $rcvar as "${name}_enable" at the end of load_rc_config() when $rcvar is undefined is bad idea. Is there any problem with removing rcvar=... in individual rc.d scripts except for non-standard ones (empty or different from ${name}_enable)? It looks simpler than writing the same line "rcvar=${name}_enable" many times in various places. -- Hiroki ----Security_Multipart(Sun_Jan__8_08_12_16_2012_123)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8I0VAACgkQTyzT2CeTzy2YggCdGmUN56/wPERmgYOs+pA+UdV7 dFoAoM7SxvTzBe7QsN8SuHXXA/RlmkGK =LirW -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jan__8_08_12_16_2012_123)----