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