Bug#604397: debian-policy: require build-arch and build-indep targets

[Jonathan Nieder <jrnieder@gmail.com>]

user debian-policy@packages.debian.org
usertags 604397 + normative discussion
quit

(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,

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 <rleigh@debian.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
order:

 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
buggy, today.

>>> 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

	debian/rules build-arch
	if test "$?" = 2
	then
		debian/rules build
	fi

.  In http://bugs.debian.org/72335 the only argument against that I
see is

	(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
	    debian/rules build
	else
	    debian/rules build-arch
	fi

	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.

Regards,
Jonathan