Bug#604397: debian-policy: require build-arch and build-indep targets
usertags 604397 + normative discussion
(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
Roger Leigh wrote:
[out of order for convenience]
> Just for the record, I've implemented support in debhelper's dh
> command in #604563. Once applied, this will automatically add support
> to the huge chunk of the archive using "tiny" rules files. cdbs will
> be next on my list.
debhelper 8.1.0 has such support now. Thanks!
>> * Roger Leigh <firstname.lastname@example.org>, 2010-11-21, 21:38:
>>> I'd like to propose that build-arch and build-indep be changed in
>>> Policy from "may be provided" to "must be provided" in preparation
>>> for enabling their use.
Personally, I'm all for it; ideally it would happen in the following
1. Providing build-arch and build-indep becomes a best practice.
lintian gains a check. devref encourages the practice.
2. Becomes a policy "should".
3. Becomes a policy "must".
That sounds slow, no? Yes, that's the point. I'd like to propose
that we not make most of the packages in the archive instantly RC
>>> We've wanted to fix the root problem for
>>> at least half a decade, and I'd like to get it done for wheezy.
I just noticed this gem in policy §4.9:
If one or both of the targets build-arch and build-indep are
not provided, then invoking debian/rules with one of the
not-provided targets as arguments should produce a exit status
code of 2. Usually this is provided automatically by make if
the target is missing.
So it seems to me that "dpkg-buildpackage -B" ought to be taught to
run the equivalent of
if test "$?" = 2
. In http://bugs.debian.org/72335 the only argument against that I
(and notwithstanding that we're going to require both or neither), it
should say that "debian/rules -q with one of the not-provided targets
...", because the programs which will want to test this are likely to
do something cheap like:
debian/rules -q build-arch
if [ $? -eq 2 ]; then
To try a full build only to receive an exit status of 2 would not say
whether the build failed or the target was not found.
That doesn't seem so compelling to me; in the failure case, the
autobuilder would just try to pick up where it left off and fail
again, which doesn't sound so expensive. What am I missing?
Thanks for moving this forward.