The future of set_rcvar

[Alexander Botero-Lowry]

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 ambigious, or osmething else?

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

Alex

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