Re: Consistent handling of the DEB_BUILD_OPTIONS
Zitat von Miriam Ruiz <firstname.lastname@example.org>:
2007/11/6, Neil Williams <email@example.com>:
There needs to be some agreement on what nocheck or notest means and
which one to use. For Emdebian needs, whichever name is used, the
imperative is that setting that DEB_BUILD_OPTION *must* completely
prevent the execution of any compiled program within any test suite
provided by upstream. The only checks or tests that can be implemented
outside nocheck|notest must only use system binaries from coreutils,
binutils-multiarch or one of the gcc binaries.
Some software packages, such as libcap, for example, seem to depend on
some code being autogenerated from a program executed in the target
(in this case, the generation of cap_names.h). What's the proposed way
of handling this? Is it gonna be against policy to have building
systems like this? Should the package being built just fail if it just
cannot be built with nocheck? I know those kind of building systems
are a pain in the anatomy (ass?), I'm not defending them or anything
like that, I'm just wondering what to do about them. Are they gonna be
considered RC bugs?
If the used build system can differ between a host compiler and a
target compiler, then this should not be a problem (else, you would
not be able to cross-compile linux itself).
If it doesn't, that thing is simply not cross-buildable.