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

[Jonathan Nieder <jrnieder@gmail.com>]

Steve Langasek wrote:

> I don't think a policy "should" actually moves us down that road, because
> there's no actual penalty for not complying.  The issue is *not* that
> maintainers don't, in general, implement this target (in fact, it's been
> around forever in the dh_make templates),

As a counterexample, I did not implement the target in any packages I
worked on unless they actually could benefit from the
build-arch/build-indep distinction.  There was simply no obvious
reason to do it, and the documentation gave no hint that it was a good
idea.  The devref would be a better place to put that suggestion given
the current state of things, but to say that documenting it somewhere
would accomplish nothing seems like overstating things.

> the issue is that we have no way
> of making use of it without a painful transition where lots of packages will
> FTBFS, and it's hard even to know which packages those are without trying to
> build them.

Agreed, of course.  The obvious naïve conclusions are:

 1. dpkg-buildpackage could benefit from a new commandline option for
    people to use to test the build-arch/build-indep targets *without*
    changing the behavior on autobuilders, and

 2. autobuilders could benefit from a Build-Options for maintainers to
    declare that it is safe to use the build-arch/build-indep targets
    today.

But see below.

> If we're willing to flip the switch on the autobuilders and force
> maintainers to deal with the breakage, we don't need a policy "should"
> either... we can go straight to a policy "must" as soon as the switch is
> flipped (and we should flip that switch *ASAP*, not let this question drag
> on any further into the release cycle).

Flipping that switch would imho be a bad idea in the current release
cycle anyway.  It's a huge change.

> And if we want to provide a smooth transition instead, using something like
> Joey's proposed make-first-existing-target interface in bug #598534 (as
> discussed on debian-devel in
> http://lists.debian.org/debian-devel/2010/09/msg00704.html)

I was about to say: without a full archive rebuild there is no
guarantee that that would actually provide a smooth transition,
either, since the build-arch targets are not well tested in isolation.
But that was misguided of me:

Assuming that the "build" target depends on "build-arch" and
"build-indep" and does nothing for itself, the most frightening
obvious case is a package that does too little in build-arch, relying
on build-indep to generate some other files (e.g., manpages) that are
needed for binary-arch.  Typically binary-arch would depend on build
in that case, so while breakage of this kind is possible, I don't
imagine it would be widespread.

So I'm all for this.  A test rebuild would still be comforting, of
course.

> The patch is outstanding; the make maintainer is TTBOMK currently
> unavailable for Debian work.  If there's a consensus on
> debian-policy/devel/ctte that we should go the make-first-existing-target
> route, I would be more than happy to do an NMU of make to facilitate this.

Thanks much!  If you'd like, I can try out the two patches from
Bug#598534 and send a comparison there.

By the way, shouldn't the make package be orphaned to reflect the
current reality?  Totally unrelated to the above, I would like to work
with the maintainer to see the latest upstream version of "make"
packaged in experimental, but for a while now the maintainer has been
hard to reach.