On Mon, 6 Jun 2011 02:15:37 -0700, Steve Langasek <vor...@debian.org> wrote: > If this were to be put to a vote today, I would propose the following ballot > options: > > 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]
The implementation is done now. > 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for > all packages in unstable and experimental immediately, with no fallback > if the target does not exist; requires a corresponding update to Policy > and mass updates to fix packages that fail to build as a result. As one of the few developpers that actually put work toward the issue and not merely write about it, I like to give some backgrounds The proposal 3) (which is implemented in dpkg as of today) was devised following a discussion in Debian policy bug #218893 as a compromise solution that was agreeable to everyone, then a patch to dpkg was written (bug #229357). For reasons beyond my control, the patch was actually merged only today. During that time, two attempts to use 'make' to guess whether build-arch existed were made to dpkg and reverted because they did not work in the real world. See dpkg version 1.10.15. Proposal 3 is the safest approach, does not require a flag day and preserve backward compatibility. And we have it now. (Please ensure that mails send to bugs assigned to the ctte can reach the ctte list, thanks). Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
signature.asc
Description: Digital signature
