On Sat, 23 Jul 2011 15:45:08 +0200, Steve Langasek <vorlon@debian.org> wrote: Non-text part: multipart/signed > Discussion appears to have died out on this thread, so it doesn't appear > anyone from the TC is waiting for more information in order to make up their > mind and I think it's (past) time to call a vote on this. I remain opposed to a manually-set Build-Options field, since I believe that in any package someone is willing to touch, just implementing proper separation of the targets is a far better solution. I've been fixing the targets in all of my packages as I stumble over them ever since the lintian check was added, and so far it has been easy to do the right things. > 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.) I'd be willing to consider this, and would probably vote it ahead of the make -qn options, though as in all the other cases, I'd be happier if someone actually had a patch that implements this ready to go. > Bearing in mind the statistics from [4] indicating that option 4) will break > 45% of all packages with arch-dep packages, I imagine we probably don't want > to go that route anymore. Actually, the more of my own packages I touch and fix, the more inclined I am to place option [4] first on my list! Fixing source packages just isn't that painful in practice, and I like the idea of just getting over the policy hurdle quickly without stopgap measures. However, of your current list of choices, I also consider the 'make -qn' options acceptable, and would vote all options that contain the Build-Options field alternative below further discussion. Bdale
Attachment:
pgpOlmnH89Qxf.pgp
Description: PGP signature