The future of set_rcvar

[Brooks Davis]

On Wed, Jun 07, 2006 at 12:04:40AM -0700, Doug Barton wrote:
> [FYI, the convention on the FreeBSD lists is not to top-post]
> 
> > Brooks Davis <brooks at 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.

I think the spelling out of the setting of rcvar has some value, but I
also think less code is good, hence option three which makes then
_enable case entirely implicit.

> >> - 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.

This is option three, described less ambiguously.  I meant rcvar="" rather
than unset above.

> >> 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.

I think it's important because people will cut and paste from the first
random script they find that looks vaguely like what they want.  If they
aren't consistent we get rapidly increasing inconsistency.  I'm also
somewhat personally annoyed that we had a style and then you started
telling people to use a different one.  It's not that big a deal, but
if we're going to review submissions for style, we should actually have
one.  I'm a firm believer that any style, even one with historical warts,
is better than none.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20060607/555655fe/attachment.pgp