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

draft ballot: please rule on how to implement debian/rules build-arch

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

 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.

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

Reply to: