Bug#156546: debian-policy: we should require a build-arch rule
The Build-Depends-Indep feature only refers to tools used by the
binary-indep target, whereas a number of packages make use, in the
"indep" part of the build rule, of specific tools (mostly, dsssl or
xsl processors). Since there is only one "build" target, it is not
possible to make those tools part of the Build-Depends-Indep list, and
those tools are launched by every run of the build-daemon, even when
the result files (eg. docs) are only included in an arch-indep package.
Not only this wastes CPU time on the build daemons (openjade, for one,
is quite resource-hungry), but it causes problems on archs where those
tools required only for arch-indep stuff have not been ported yet.
As an example, the "bigloo" package needs "scribe" to build its docs.
However, "scribe" build-depends on "bigloo". When scribe became
functionnal on i386 I activated the build of the docs, but now bigloo
can only be built on packages where scribe is working.
We could standardize a "build-indep" rule (and, possibly, its
build-arch counterpart, although I'm not sure this one would be
useful), and allow binary-indep to depend on build-indep only.
For backwards compatibility, in packages making use of this, "build"
would be required to depend on "build-indep". For packages that do
not need this extra flexibility, the build-indep target could just
depend on the build target.
Autobuilders would run "debian/rules build-indep" instead of
"debian/rules build" when the standards-version of the package is
greater or equal to the 1st version of the policy that requires
 This, however, introduces an inconsistency: in some cases we have
"build: build-indep", in others we have "build-indep: build". This
could be made more consistent by requiring "build: build-indep", but
then either we have "build-indep" as the primary name of the former
"build" rule (which would not be as accurate), or we could have some
"build-all" target on which both "build" and "build-indep" (which
would complicate stuff, maybe with no good reason)
Do you think this is solid enough to be turned into a policy
ammendement ? Would anyone second this ?
Yann Dirson <Yann.Dirson@fr.alcove.com> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer (firstname.lastname@example.org) Développeur Debian