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.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110604043213.GA12175@elie
