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

[Raphael Hertzog]

On Thu, 10 Jul 2008, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the
> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.

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.

The meaning of each build options is specific to each, there's no global
rule that works for all cases. That's why we have documentation of each
option in dpkg-buildpackage.

> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

There are dozens of ways to "abuse" any interface if you choose to use
it in a way that contradicts the documentation. But that's not a reason
to limit the flexibility offered by an interface.

Cheers,
-- 
Raphaël Hertzog

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Bill Allombert]

On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the

Maybe it is not obvious, but since noone proposed another working
solution in the ten years this issue exists, there is no alternative.

> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.
> OTOH, it gives the benefit of being able to ignore the package capabilities 
> via the environment (ie, unset a given option).
> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

I concur. This also create a namespace problem by conflating the
'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace.
Since a developer can put virtually anything in DEB_BUILD_OPTIONS
(and check for it in debian/rules) even if it is not mentionned 
in policy, this is a real issue.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Joey Hess]

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

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.

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

-- 
see shy jo

[1] A gentoo guy. Who better to discuss build options. ;-)
[2] http://farm2.static.flickr.com/1121/639896787_dfe8d0f8c2.jpg


signature.asc
Description: Digital signature

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

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> 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?

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).  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.
They're going to have to test each flag that goes into the hardening
options separately anyway to make sure that it works (the current proposed
hardening flags break many packages, and if you follow debian/changelog
files, you'll see that many maintainers have added them blindly and then
had to roll back when they break).

Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage
is a solution looking for a problem, IMO, and I'd rather not see that
tangled up with the much-needed problem of specifying which options a
package supports and finally dealing with the whole build-arch/build-indep
mess.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]