Hi folks,
Discussion appears to have died out on this thread, so it doesn't appear
anyone from the TC is waiting for more information in order to make up their
mind and I think it's (past) time to call a vote on this.
I am expanding on the original set of ballot options I'd proposed to include
additional options brought up during the discussion that I've seen support
for from the TC members. If I've missed any options that you would like to
vote for, please say so.
I've also made it explicit that each of these options are intended to be
transitional, and that we eventually want build-arch to be used
unconditionally to avoid the extra heuristics in the build tools.
BTW, another option for the long-term solution which we haven't really
addressed head-on is that dpkg-buildpackage could detect whether both
arch-indep and arch-dep packages are present in debian/control, and use
build-arch *only* when both are present. This does not require either
heuristic detection (the presence or absence of arch-indep/arch-dep packages
is *definitional* of whether a separate build-arch rule is relevant, and
dpkg-buildpackage already parses debian/control), or the use of redundant
declarations (i.e, Build-Options). Should we incorporate this into the
ballot options? (For the avoidance of combinatoric proliferation, I'd
prefer to decide this question by acclamation and either incorporate it into
all the ballot options, or not.)
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] After a transition period this target will be made
mandatory.
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] After a transition period
this target will be made mandatory.
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]
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.
5) Implement support for calling 'debian/rules build-arch' in place of
'debian/rules build' if either it's found to be present with 'make -qn'
or if a Build-Options field is set in debian/control specifying that the
target is supported. It is recommended to only use Build-Options in
cases where autodetection fails.
6) Further Discussion
Bearing in mind the statistics from [4] indicating that option 4) will break
45% of all packages with arch-dep packages, I imagine we probably don't want
to go that route anymore. Now, maybe excluding sources that *only* build
arch-dep packages with no accompanying arch-indep packages would reduce this
percentage, but I doubt it would help enough to change anyone's vote so am
not inclined to spend more time gathering that information.
Thanks,
--
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
[1] http://lists.debian.org/debian-devel/2007/07/msg00048.html
[2] http://bugs.debian.org/598534
[3] http://bugs.debian.org/229357
[4] http://lists.debian.org/debian-ctte/2011/06/msg00034.html
Attachment:
signature.asc
Description: Digital signature