On Mon, Jun 06, 2011 at 03:59:15PM +0200, Bill Allombert wrote: > On Mon, Jun 06, 2011 at 12:09:34PM +0200, Bill Allombert wrote: > > On Mon, Jun 06, 2011 at 02:15:37AM -0700, Steve Langasek wrote: > > > 1) Implement support for calling 'debian/rules build-arch' in place of > > > 'debian/rules build' by checking for the presence of the target using > > > 'make -qn'.[1] > > > > > > 2) Implement support for calling 'debian/rules build-arch' with a fallback > > > to 'debian/rules build' by checking whether the output of the build-arch > > > target matches that of a dummy target.[2] > > > > > > 3) Implement support for calling 'debian/rules build-arch' in place of > > > 'debian/rules build' if a Build-Options field is set in debian/control > > > of the source package specifying that this target is supported.[3] > > > > For the record, I have been working to the patch that implement 3) to get accepted, > > see bug #229357. > > Still for the record this patch has been accepted in dpkg as of today: > http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef > Does that make this bug moot for all concerned ? > > I plan to repropose #218893 with updated wording to match this dpkg change. This is great, thanks for doing this! Has the following been considered: - adding a command-line option for dpkg-buildpackage to explicitly enable particular build-features (overriding the feature in the source package). This would allow us to test build the whole archive with the build-arch and build-indep targets enforced. And it would also permit the buildds to switch to using them by default in the future. And it would also allow the dpkg-buildpackage defaults for that particular setting to be altered in the future as well. The question to consider here is whether or not this particular build feature is "transitional" or if it will remain indefinitely. Needing to explicitly enable a target that should be the default is something I'm not that happy with. While it's fine to do this as a means of transitioning with minimal breakage, and I'm totally OK with this as a means of getting the transition done, I would prefer it not be a requirement in perpetuity. Once the archive has sufficient coverage to make mandating the targets a realistic possibility, I would be all for making it mandatory. Now that dpkg-buildpackage can safely utilise the build-arch and build-indep targets with the build feature enabled, we can make any required changes to sbuild's build dependency handling to get it used on the buildds. Currently we - always install Build-Depends and remove Build-Conflicts - always build binary-arch packages - build binary-indep packages in addition on request - install Build-Depends-Indep and remove Build-Conflicts-Indep if building binary-indep packages We don't currently have an option to build /only/ binary-indep packages, but this might be useful for arch-all autobuilding if we don't want to build them at the same time as for binary-arch. In this case, would we still want to install Build-Depends and Build-Depends-Indep? (I would think so.) We don't currently have a Build-Depends-Arch and Build-Conflicts-Arch; but this might be useful. This would allow Build-Depends to be used for "generic" dependencies required for both build-arch and build-indep, e.g. debhelper, cdbs etc. And it would mean that when doing a binary-indep-only build, the buildd won't need to install masses of -dev packages which won't be used, since they would be in Build-Depends-Arch. (Enabling Build-Depends-Arch/Build-Conflicts-Arch in sbuild is a trivial change which could be done today.) This would be nice because there's then a 1:1 correspondence between build, build-arch, build-indep and the Build-Depends, Build-Depends-Arch and Build-Depends-Indep fields, respectively (and the same for conflicts). 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