[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#604397: Request for TC to rule on a course of action for supporting build-arch



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/
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

Attachment: signature.asc
Description: Digital signature


Reply to: