From owner-freebsd-rc@FreeBSD.ORG Wed Jun 7 07:12:29 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A606F16AF88 for ; Wed, 7 Jun 2006 07:04:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id E3F5F43D48 for ; Wed, 7 Jun 2006 07:04:42 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 1058 invoked by uid 399); 7 Jun 2006 07:04:41 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Jun 2006 07:04:41 -0000 Message-ID: <44867A88.5060307@FreeBSD.org> Date: Wed, 07 Jun 2006 00:04:40 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Alexander Botero-Lowry References: <20060606205325.GA13570@odin.ac.hmc.edu> <200606062147.k56LlW3i059772@Laptop.mine.box> In-Reply-To: <200606062147.k56LlW3i059772@Laptop.mine.box> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: The future 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: Wed, 07 Jun 2006 07:12:33 -0000 [FYI, the convention on the FreeBSD lists is not to top-post] > Brooks Davis wrote: > >> We need to decide what we're doing with set_rcvar. Doug has been >> advocating against it in a number of forums, but no move has been made >> to actually deprecate it that I've seen. I believe we need to speak >> with one voice on this issue and have one style that is both documented >> for ports and used in the base. I can see three main options: Well I certainly didn't mean to stir up trouble. :) I'm also not opposed to its usage in the manner you seem to imply (although no harm/no foul either way). The reason I started "spelling it out" was to help someone understand better what was happening "behind the scenes" in rc.subr. There is a lot of power/capability in our rc.d system, but IMO there is also a lot of pointless indirection, and complication of things that could be simpler. I'm not opposed to coming up with a consistent viewpoint on this, and I will not oppose any sensible direction we choose to take. I also don't think it is necessarily that big a deal, but I'm willing to be persuaded either way. >> - Use set_rcvar unless there is a good reason not to (generally the >> very few historical scripts). This is the default in the base and was >> the status quo in ports for a while. >> - Always manually set $rcvar, >> deprecating set_rcvar with a loud warning and removing in in 7 or 8. >> - The same as above, but default $rcvar to ${name}_enable requiring that >> scripts that don't use have an rcvar value explicitly unset it. I would like to suggest a fourth option (unless I misunderstand your third option above), which is for rc.subr to do this: : ${rcvar=${name}_enable} IOW, the default will be ${name}_enable unless the port sets a different value, or sets the value to null. I would hesitate to literally use/encourage unset, especially in ports where the interaction between scripts and rc.subr is harder to follow closely and things are more likely to break in weird ways. >> I slightly prefer the first or third option because I don't like the >> idea of the default style encouraging inconsistent naming which I >> believe forcing rcvar to be set manually by default does. My only >> strong opinion on the subject is that we must make up out minds and act >> consistently instead of continuing the current split between ports >> documentation and the base. I'd be interested to hear why you think this is a matter of some importance. As a data point, out of 133 /etc/rc.d/ scripts on my 6-stable box, 32 do not use set_rcvar. 2 of the 32 (including named :)) set name_enable explicitly, 3 unset rcvar, and the rest set it to something-not-name_enable. Alexander Botero-Lowry wrote: > One question I've always had is why FreeBSD picked to have ${name}_enable > instead of just ${name} like on NetBSD? Was there a lot of debate about > this, was it to make the variables less ambiguous, or osmething else? Hysterical raisins. The rc.conf variables on FreeBSD have always been foo_enable, since long before rc.d was imported. It was decided to keep things consistent to minimize the impact on users during the rc.d import. > I would advocate for the third option if there is really a good reason to > not just do what NetBSD does. It makes it hard for packagers to use > consistent rc scripts between NetBSD and FreeBSD when the $rcvar is > different between the two platforms (and with a lot of stuff in ports and > pkgsrc the same rc scripts could be used and even packaged with the > application if upstream likes that idea). The original goal of the rc.d import was to share code between the two systems, but it quickly became obvious that this was not a practical goal, as there are enough fundamental differences between how the systems are started that the cost::benefit ratio went too high too fast. That goal has basically been abandoned for some time now. The one port I know of that tried to have a script that was generic enough to work on both systems was so broken on FreeBSD that it needed to be replaced, so I'm not sure that this is a useful goal either. However, if there is a groundswell of support for it, we could certainly work something out. If we followed my suggestion above, we would actually not have to change set_rcvar in any way, we'd just add a note in the code (and man pages, docs, etc.) that its use is deprecated, and make sure that nothing in the base uses it (so as to avoid having confusing examples). Then again, some might see that as the same kind of ambiguity that we have now, so we'd have to have this conversation all over again. :) In any case, I hope that this clarifies my thinking a bit more, and once again, not really trying to stir up any trouble here. Doug -- This .signature sanitized for your protection