On Tue, Jun 07, 2011 at 09:41:18AM +0200, Raphael Hertzog wrote: > On Mon, 06 Jun 2011, Steve Langasek wrote: > > If this were to be put to a vote today, I would propose the following ballot > > options: > > 1) Implement support for calling 'debian/rules build-arch' in place of > > 'debian/rules build' by checking for the presence of the target using > > 'make -qn'.[1] > > 2) Implement support for calling 'debian/rules build-arch' with a fallback > > to 'debian/rules build' by checking whether the output of the build-arch > > target matches that of a dummy target.[2] > > 3) Implement support for calling 'debian/rules build-arch' in place of > > 'debian/rules build' if a Build-Options field is set in debian/control > > of the source package specifying that this target is supported.[3] > > 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for > > all packages in unstable and experimental immediately, with no fallback > > if the target does not exist; requires a corresponding update to Policy > > and mass updates to fix packages that fail to build as a result. > > 5) Further Discussion > I suggest a supplementary option that combines 4 and 1. And I attach the > corresponding dpkg patch. > --- > Turn on direct use of "debian/rules build-arch" unless the package seems > to be missing the target according to "make -qn". In that case output a > warning that asks the packager to implement the required targets, but > fallback to using the "build" target. > The fallback to build and the "make -qn" auto-detection is temporary to > ease the transition but should dropped at some point (wheezy+1, or > wheezy+2). The policy should document that the targets must be supported. > --- This actually reads to me the same as option 1. What distinction are you meaning to draw here? It's not very "direct" use of build-arch if we're checking 'make -qn' first. The only other differences I see here are issuing a warning, and explicitly declaring to put this in policy now and that the auto-detection will eventually be deprecated. To me these all seem like implementation details that don't need to be ruled on in order for the TC to make its decision, but I'm also happy to have these spelled out in option 1 if that's the consensus. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature