On Mon, Jun 06, 2011 at 02:33:22PM +0100, Roger Leigh wrote: > 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. I don't think that's true at all. If we go with one of the autodetecting implementations, there's no need for a policy "should"; we can go straight to a list of policy "musts" for the required interactions between Build-Depends and build-arch. Recommending that maintainers *take advantage* of the possibility to properly split Build-Depends and Build-Depends-Indep is not really very interesting to me, once that's done. > > 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. Hack or not, once implemented I expect any automatic fallback handling to be with us for a while. I think it's realistic to have build-arch supported for wheezy, but I'm not sure we would want to make it mandatory even in wheezy+1, because the last packages to implement it are going to be those that also get no benefit from it. So this comes down to Policy (and the buildds) not making a large number of packages instantly buggy without good reason, and I think it's premature to worry about sunsetting make-first-existing-target before we've even started to use it. (Incidentally, if the consensus is that make-first-existing-target is a "bit of a hack", then I agree with Guillem that it shouldn't be put in the make package at all, just in dpkg-buildpackage.) > > 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. Have you tried to quantify these false positives? IME where maintainers have resisted adopting either dh or cdbs, it's usually *because* they have their own complex build systems, with pattern rules and includes, that are not straightforward to convert (if they're willing to 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. > 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. 'make -qn' is already an adequate facility for this. The only disadvantage to adopting it for build-arch is that not all packages use a policy-compliant makefile for debian/rules. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
