On Tue, Jul 26, 2011 at 10:32:12PM +0200, Carsten Hey wrote: > * Steve Langasek [2011-07-23 15:45 +0200]: > > 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). > An other option is to release a new Debian Policy version (maybe a major > one), including either the requirement for source packages with > arch-indep and arch-dep packages to provide build-arch (what you > described above), or require all packages to provide build-arch as > target; and during a transition period, let dpkg-buildpackage use the > Standards-Version of a package to decide whether the build-arch target > should be used. I would not vote such an option above FD and would expect it to be entirely dominated by the ballot option to use a Build-Options flag instead; so I won't include this on a proposed ballot unless another member of the TC says this is interesting to them. I think there is a very clear consensus in the community that the value of the Standards-Version field should never affect the behavior of build tools. -- 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