On Fri, Jun 03, 2011 at 05:09:33PM +0100, Roger Leigh wrote: > > > Just for the record, I've implemented support in debhelper's dh > > > command in #604563. Once applied, this will automatically add support > > > to the huge chunk of the archive using "tiny" rules files. cdbs will > > > be next on my list. > > debhelper 8.1.0 has such support now. Thanks! > With dh and cdbs both supporting build-arch and build-indep automatically, > we are now in the situation that >50% of the archive supports these rules. > Is there any reason we can't now make build-arch and build-indep a "should" > in policy? How does adding this to policy help us get to the point where we're willing to turn on use of build-arch on the buildds? 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), 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. If people want to track those packages down and NMU them today, they don't need a policy "should" to do so. Nor is a policy "should" likely to make the set of packages in need of an NMU for this any smaller. 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). 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), we don't need this to be a policy "should" or "must" at all, because the autobuilders can then DTRT for any package whether or not it implements the build-arch target and the presence of the target merely lets us optimize build times and reduce build dependencies - so it could remain a policy "may" indefinitely (with some tightening of the language about how not having build-arch requires different bits to be in Build-Depends than if you do have it). > > 1. Providing build-arch and build-indep becomes a best practice. > > lintian gains a check. devref encourages the practice. > I wrote a lintian check which is currently in a patch proposed as lintian > bug #605012. I'm not sure if it needs to be in Policy before or after > it's implemented in lintian? I thought lintian reflected policy for the > most part. > It probably needs a little more polish (testsuite support) before it can > be applied, but the core checks are done. Unfortunately I see the same problem with this lintian check as with all the rest - if we can actually check for the existence of the target *reliably*, then we don't need to enforce its presence at all. > Is there any recent work on the rules checking in make which would allow > dpkg-buildpackage to use the rules if present, but fall back to build > if absent? This would be the most pragmatic approach, because it will > both provide backwards compatibility with all older source packages, and > use the rules if present in new ones. 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. -- 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