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

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


					yours,
					dillo