Re: New Build-Options field and build-arch option, please review

[Raphael Hertzog <hertzog@debian.org>]

Hi,

thanks for your answers.

On Fri, 11 Jul 2008, Joey Hess wrote:
> 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?

This might be possible but the limit is not always very clear: in the case
of build-arch, the simple fact that it's supported means that it's enabled
by default. 

It doesn't really make sense to require the maintainer to put it in
Build-Options-Supported and also in Build-Options.

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

You're thinking of options in terms of configure flags, is that right?
--with-mysql might be incompatible with --with-postgresql but both might
coexist with yet another feature.

I'm not sure I want to go that far in the logic of Build-Options. I
certainly would consider nice to have a sort of "flavor" mechanism
where the maintainer can propose various combinations of options.

Build-Options-Supported: flavor=mysql,postgresql,oracle,all
Build-Options-Default: flavor=all

But we could also express this with:
Build-Options: possible-flavor=mysql,postgresql,oracle,all
 default-flavor=all

(Well the set of prefix can be discussed and set in stone, exactly like
I have used the "no-" prefix to disable an option previously set)

> Also, I think it would be a good idea to explicitly make "x-foo" be
> reserved for non-standard options.

Fine.

On Fri, 11 Jul 2008, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > 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... if you check the case that I listed above, we
> > also want to use Build-Options to _enable_ specific hardening
> > measures. Because the maintainer knows best which hardening measures
> > should be enabled. But we also want the builder to be able to override
> > them for example to test if the package now supports a previously
> > disabled hardening measure.
> 
> This doesn't make sense to me.  The maintainer writes debian/rules; why
> would they need to change Build-Options in debian/control to enable
> anything about the build?

Because they want that anyone can easily rebuild it with that option
disabled?

> I'd rather see Build-Options in debian/control be clearly defined as
> capabilities that the package supports and not used as a substitute for
> the existing DEB_BUILD_OPTIONS method of controlling what the build does
> in practice.  (And I'd prefer it to be called Build-Options-Supported or
> something along those lines.)  I think this still fits for #489771; the
> presence of the hardening option in Build-Options-Supported indicates that
> the package can usefully be built with hardening (it doesn't cause the
> package build to break or the binaries to malfunction).  

Separating the two meanings is always possible, see above for a
discussion.

> If the package maintainer wants the package to always be built with
> those options, they should make that change directly in debian/rules,
> not via this method.

Why? (and it's not "always", it's by _default_)

I find it rather nice that we have a common way to enable this for all
packages: add a hardening-wrapper to Build-Depends, add the option
indicating which of the hardenings flags to enable, and you're done
and it works for all packages.

Of course, you can also set the right variables in debian/rules directly
but then you make it complex for anyone to disable those build options
(for example to verify if a failure can be attributed to one of these
hardening options).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/