unmerge 604397 clone 604397 -1 reassign -1 tech-ctte retitle -1 Please rule on how to implement debian/rules build-arch merge 345619 604397 thanks
Fellow Committee members,
I am requesting your assistance in helping the project come to a conclusion
about how we can support the use of the 'build-arch' debian/rules target on
autobuilders, letting us at long last split Build-Depends and
Build-Depends-Indep the way they're meant to be split.
As you can see from the history of the source bug, this question has
lingered for some time - the first policy bug having been opened over 5
years ago. I believe it has remained unresolved principally because we have
several different ways that the problem could be solved, each of which is
better than not solving it but none of which is overwhelmingly superior to
the others. As a result, it has taken longer to decide how to implement
this than it would have taken us to actually implement it, even using one of
the methods that require touching every affected package in the archive.
I think that makes this one of the rare cases where the TC can usefully move
Debian forward by voting rather than by seeking consensus, because the root
problem here is the *lack of a decision* rather than any real technical
dispute about the right course of action.
The Technical Committee has sufficient authority to address this question
under any of ยง6.1.{1,2,4,5}. If you prefer, we could also ask for a
referral from the policy editors or the dpkg maintainers, to eliminate any
question of supermajority requirements.
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]
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) Further Discussion
None of these options require extensive design work on the part of the TC;
where patches don't already exist, the implementation should be trivial.
I'm happy to expand on each of these options and present the pros and cons
as I see them, or you can each peruse the extensive historical record at
your leisure... :)
My own vote would likely be: 1, 2, 3, 5, 4. (I could be persuaded to rank 4
above FD if this were the only way to move forward; but that's indisputably
the most disruptive to the archive, so I would hope we could reach agreement
that some or all of the other options are better.)
Cheers,
--
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
[1] http://lists.debian.org/debian-devel/2007/07/msg00048.html
[2] http://bugs.debian.org/598534
[3] http://bugs.debian.org/229357
signature.asc
Description: Digital signature
