Bug#218893: Build-Options and build-arch, noopt, nostrip, ...
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
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
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
* 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.