Bug#218893: Build-Options and build-arch, noopt, nostrip, ...
On Thu, Aug 16, 2007 at 03:07:04PM +0200, Loïc Minier wrote:
> Hi,
>
> There are many requests to:
> - gradually add support for "build-arch" targets in packages
> - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS
I am concerned with conflating this two issues which are very different
in nature. DEB_BUILD_OPTIONS require much more flexibility than build-arch.
> - add various new fields to DEB_BUILD_OPTIONS
>
> I like the proposed Build-Options approach to document what a package
> supports or not, but I don't like the fact that packages would be
> required to list an always longer list of flags when these are required
> by policy.
>
> I propose:
> 1) to allow the Build-Options field in source packages to document that
> a package supports these comma-separated build-options
> 2) to document the Build-Options a package MUST and SHOULD implement in
> the current policy version
That does not really work: you cannot make a lot of packages RC buggy
just by changing the requirement for a Build-Option in a new policy
. So once the meaning of a build-option is decided, it need to stay
essentially fixed.
> 3) to allow the special "standard" keyword in Build-Options to mean "any
> option required by the policy version in Standards-Version"
This make handling of Build-Options by build scripts too hard in my
opinion. Furthermore, this was essentially opposed in the discussion of
this bug, and I finally proposed Build-Options to address them.
There were concerns that:
1) packaging will become more complex over time by increase in
requirement.
2) the notion that "newer is better" will lead packages to acquire
useless interface just because it is the most recent version of
policy.
Build-Options was really meant to be at the option of the packager,
hence the name Build-Options, and not Build-Standard.
Policy can enforce new interfaces by itself without the use of
Build-Options.
> 4) to document that the absence of a Build-Options field means
> "Build-Options: standard"
Then what is the point of "standard" ? To allow package to not implement
a Build-Options by using Build-Options: nostandard ? This seems backward.
> 5) to document the following Build-Options:
> * nostrip: meaning the package wont strip binaries which can be built
> with debug symbols from the resulting packages
> * noopt: meaning the package will be built with all optimizations
> turned off
> * build-arch: meaning the debian/rules supports the build-arch targe
> to only build arch any packages
As I said I do not like to conflate them: build-arch describe the
interface to build binary packages suitable for the main archive
by developers and buildd.
nostrip/noopt describe ways to build debugging packages that should not
be uploaded to the main archive. If the option is not implement, policy
require that the package is build normally.
Maybe what you want is a field Build-Standard.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: