Re: New Build-Options field and build-arch option, please review
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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: