Joey Hess <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]