Subject: Re: usage of USE_INET6
To: Georg Schwarz <firstname.lastname@example.org>
From: Dieter Baron <email@example.com>
Date: 11/21/2005 16:00:41
In article <E1EdyIu-0004Gn-Uf@mikro.physik.TU-Berlin.DE> Georg wrote:
: > I do not understand how this is related to the question. Using
: > "BUILD_DEFS+=USE_INET6" did nothing to enforce the IPv6 capability, so
: > how does deleting this line change anything?
: > If a package unconditionally needs IPv6, then "inet6" is not really
: > an option for this package at all, since it should be possible for
: > options to be disabled as well as enabled.
: I think this is a valid point. We should be very careful with semantics
: in order not to make things more confusing than necessary.
: In my opinion we need the following functionality:
: a) a way for a package to indicate that it can support IPv6
: b) a way for a package to indicate that it needs IPv6 support to compile,
: i.e. always compiles with IPv6 support.
: c) a way for a package to indicate that there is some sort compile time switch
: to decide whether to use IPv6 support or not. This is what USE_INET6 if for
: so far and which the inet6 option is about to take over.
: Of course c) and b) each imply a), but both contain more information than
: a). (as a side note, a) does not necessarily mean b) or c) since one could
: imagine a case where a package by its own means decides whether to use IPv6
: but does not provide a compile time switch for it; not very desirable,
: I admit).
Some packages use the getaddrinfo API if available and have runtime
switches to disable IPv6, which, IMO, is prefectly reasonable.
: My feeling is that it makes little sense to have the switch in c) set per
: package. I cannot think why it should make sense on a given system to
: decide per package to compile with IPv6 support or not. In contrast, it makes
: a lot of sense to have such a global switch, as we used to with USE_INET6.
Don't limit a user's choices unnecessarily. Imagine someone who
builds a package on his workstation (which has IPv6 support) and wants
to use it on a server system without IPv6 support. He may very well
want to disable IPv6 support for that package only.
I think a genreal solution would be better than some ad-hoc method
specifically for IPv6 support. The features USE_INET6 has shown
lacking from the options framework:
1) a way to globally enable an option by default (what
PKG_SUGGESTED_OPTIONS does for one package)
2) a way for a package to specify that an option must be enabled
3) a way for a platform to specify that an option cannot be enabled
For 1) I would suggest a new variable,
PKG_GLOBALLY_SUGGESTED_OPTIONS, that bsd.pkg.mk and platform-specific
files can set. This variable can be overridden by
PKG_SUGGESTED_OPTIONS by individual packages.
For 2) I made a suggestion in reply to a mail by Todd a while back
(PKG_OPTIONS_REQUIRED_OPTIONS). The question here is if we really
want options that cannot be disabled (which sounds contradictory, but
it does what we want).
For 3) we could introduce a new variable, PKG_DISALLOWED_OPTIONS
that bsd.pkg.mk or platform specific files can set to a list of
options. If the user enabled any of them, the package build fails.
: I would like to take the opportunity to check whether I correctly
: understood the various options variables:
: PKG_SUPPORTED_OPTIONS: lists the options supported by that package
Correct. (Options from option groups and sets are added to this
variable by bsd.options.mk)
: PKG_OPTIONS_VAR: name of the options variable for that package
Yes. The user can set this variable in MAKECONF to specifically
select/deselect options for this package.
: PKG_DEFAULT_OPTIONS: default settings (with - prefixes to cancel out
: a specific option). Is that to be set per package or globally?
No, the user can set this variable in MAKECONF to select/deselect
options for all packages (that support them).
: Should packages make sure to always use PKG_DEFAULT_OPTIONS+= ?
Packages should *never* change PKG_DEFAULT_OPTIONS, it is a user
: What is the difference to PKG_SUGGESTED_OPTIONS?
Packages can set this variable to specify which options are enabled
by default (if the user sets neither the variable named in
PKG_OPTIONS_VAR, nor PKG_DEFAULT_OPTIONS).
The naming of PKG_DEFAULT_OPTIONS and PKG_SUGGESTED_OPTIONS is
somewhat awkward, but PKG_DEFAULT_OPTIONS was a user settable variable
before the overhaul of the option specification system, and it was
deemed better not to break existing configurations.