Date: Mon, 09 Jan 2012 22:35:10 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: dougb@FreeBSD.org Cc: freebsd-rc@FreeBSD.org Subject: Re: Making use of set_rcvar. Message-ID: <20120109.223510.1979757999064039809.hrs@allbsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Mon_Jan__9_22_35_10_2012_563)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Doug Barton <dougb@FreeBSD.org> 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 <dougb@FreeBSD.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120109.223510.1979757999064039809.hrs>