Date: Wed, 07 Jun 2006 00:04:40 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Alexander Botero-Lowry <alex@foxybanana.com> Cc: freebsd-rc@freebsd.org Subject: Re: The future of set_rcvar Message-ID: <44867A88.5060307@FreeBSD.org> In-Reply-To: <200606062147.k56LlW3i059772@Laptop.mine.box> References: <20060606205325.GA13570@odin.ac.hmc.edu> <200606062147.k56LlW3i059772@Laptop.mine.box>
next in thread | previous in thread | raw e-mail | index | archive | help
[FYI, the convention on the FreeBSD lists is not to top-post]
> Brooks Davis <brooks@one-eyed-alien.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44867A88.5060307>