On Fri, Jun 03, 2011 at 08:25:11PM -0700, Steve Langasek wrote: > 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. […] > 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. My main objective to make it a "should", and implementing the lintian check in addition, is that we would have a transitional phase where all developers would be - made aware of the changing requirement for the targets - be told about the deficiency when they run lintian - have time to transition their packages before it becomes a "must". While neither of these changes actively "enforces" the addition of these targets, neither do any harm, and by actively encouraging adoption of the targets it will reduce the total number of NMUs required should we go for the approach of a straight change in dpkg-buildpackage. Neither of these dictate /how/ the transition should proceed, which is a separate issue which you brought to the CTTE, but both will be needed irrespective of the choice picked by the technical committee. > 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). This would make sense if we do want to go the "break the world" route; the above does not preclude that, but does allow for a (potentially very brief) period to allow for maintainers to pre-emptively fix their packages before the change is made. I'm certainly not opposed to this approach if the decision is made to go this way. > 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). I would see make-first-existing-target as a good method for easing the transition, and we could leave it a "may" indefinitely. But would it not be better (long-term) to aim for complete transition to requiring build-arch/build-indep for all packages (as for binary-arch/ binary-indep) and use make-first-existing-target as a useful strategy for doing the transition, but not as a long-term feature? Especially since it's a bit of a hack. > > > 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. (This patch is now complete including the testsuite and ready to go.) > 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. It isn't 100% reliable (it can't be given pattern rules and includes); it gives up for dh/cdbs-using packages, but both of these handily already support the missing targets, so it's reliable enough to be useful. If the maintainer chose to use odd pattern rules, these could potentially cause a false positive. > > 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. As a medium-term solution it would be great if GNU make could itself support querying whether or not a makefile supports a given target. Since make needs to parse all the includes etc., only make itself can do this 100% reliably. If it's not already done, a feature request upstream would be good. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature