Bug#218893: Build-Options and build-arch, noopt, nostrip, ...

[Loïc Minier <lool@dooz.org>]

        Hi,

 There are many requests to:
 - gradually add support for "build-arch" targets in packages
 - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS
 - 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
3) to allow the special "standard" keyword in Build-Options to mean "any
   option required by the policy version in Standards-Version"
4) to document that the absence of a Build-Options field means
   "Build-Options: standard"
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


 This differs from the original proposal in that it wont require
 packages implementing all required options to have a possibly long
 Build-Options field over the years.  It also explicitely permits
 requiring support for some build-options and recommending support for
 some other based on the standards-version.


 It would be nice if policy could back up support for Build-Options so
 that we can add the field to source packages and start producing some
 metrics of "number of packages supporting option foo" to propose
 release goals or to update the standard requirements in policy.

-- 
Loïc Minier