On Sun, Jul 24, 2011 at 08:14:55PM +0200, Guillem Jover wrote: > On Sat, 2011-07-23 at 15:45:08 +0200, Steve Langasek wrote: > > BTW, another option for the long-term solution which we haven't really > > addressed head-on is that dpkg-buildpackage could detect whether both > > arch-indep and arch-dep packages are present in debian/control, and use > > build-arch *only* when both are present. This does not require either > > heuristic detection (the presence or absence of arch-indep/arch-dep packages > > is *definitional* of whether a separate build-arch rule is relevant, and > > dpkg-buildpackage already parses debian/control), or the use of redundant > > declarations (i.e, Build-Options). Should we incorporate this into the > > ballot options? (For the avoidance of combinatoric proliferation, I'd > > prefer to decide this question by acclamation and either incorporate it into > > all the ballot options, or not.)
> In the thread in debian-policy I also proposed [0] another small variation > for this, which would imply a two stage transition, reducing the immediate > simultaneous FTBFS. Jakub Wilk provided numbers [1] for the possible FTBFS > on the non-staged scenario. > [0] <http://lists.debian.org/debian-policy/2011/06/msg00026.html> > [1] <http://lists.debian.org/debian-policy/2011/06/msg00018.html> I think this is too much hair splitting. To be clear, I was proposing a change to our *desired end state*, but that the ballot options to choose between would otherwise remain the same - and I'm still in favor of getting the ball rolling using the make -qn heuristic check. And if we're using the heuristics to reduce the initial FTBFS set, another intermediate stage is unnecessary. -- 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/ [email protected] [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
