Re: New Build-Options field and build-arch option, please review
Joey Hess <joeyh@debian.org> writes:
> Raphael Hertzog wrote:
>> Even if there's only two things, the fact is that the package maintainer
>> wants not only to decide what is supported but he might also want to
>> enable some features...
>
> Did you think about having two fields, one to specify the set of
> supported options, and one to allow setting defaults?
>
> FWIW, Manoj, Steve, Yuri[1] and I had a good chat about this on the
> train across Scotland last summer.
>
> For some types of options, it makes sense to not just declare that
> they're supported, but that some particular combinations of options is
> supported, while declaring other combinations as unsupported. This would
> be particularly useful when setting compile options (including librarary
> link combinations).
Similary the user might want to enable options that are supported,
force enable (override) options that are undeclared or forbidden or
disable options that are declared as default. It should be possible to
specify a delta or mask to the packages options and not just set the
options, e.g. to say "use default options + bar - foo".
> Hmm, my notebook[2] from that trip suggests the following syntax:
>
> Build-Options: strip, debug, bar, foo, !foo+bar
>
> Indicating that foo and bar cannot be combined.
Should that be more like
Build-Options: strip, debug
Build-Supported: bar, foo, !foo+bar, !baz
Indicating that strip and debug should be used by default. Further bar
and foo may be enable but not together and baz must not be used.
Not that !baz would be different from not listing baz. !baz would be a
strong indicator that the build will break.
> Also, I think it would be a good idea to explicitly make "x-foo" be
> reserved for non-standard options.
Further I think it would be good if one could say "use bar if
supported" in an environment variable or conffile. For example the
user might want to use parallel building with 2 cores if the package
supports it. But if the package does not then there should be no
error. Otherwise one would have to change the environment for every
build according to the package capabilities.
MfG
Goswin
Reply to: