« Return to Thread: New Build-Options field and build-arch option, please review
Re: New Build-Options field and build-arch option, please review
by Felipe Sateler
::
Rate this Message:
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.
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.
Saludos,
Felipe Sateler
> 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.
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.
Saludos,
Felipe Sateler
signature.asc (204 bytes) « Return to Thread: New Build-Options field and build-arch option, please review
| Free Forum Powered by Nabble | Forum Help |
