Date: Tue, 06 Jun 2006 17:47:31 -0400 From: Alexander Botero-Lowry <alex@foxybanana.com> To: freebsd-rc@freebsd.org, brooks@one-eyed-alien.net Subject: Re: The future of set_rcvar Message-ID: <200606062147.k56LlW3i059772@Laptop.mine.box> In-Reply-To: <20060606205325.GA13570@odin.ac.hmc.edu> References: <20060606205325.GA13570@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606062147.k56LlW3i059772>