Debian Bug report logs - #629385
Please rule on how to implement debian/rules build-arch

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: debian-policy: build-arch and build-indep targets are required

Date: Sun, 21 Nov 2010 21:38:31 +0000

[Message part 1 (text/plain, inline)]

Package: debian-policy
Version: 3.9.1.0
Severity: normal
Tags: patch

Hi,

As a goal for wheezy, I'd like the Build-Depends and
Build-Depends-Indep fields to be fully functional and usable for
autobuilding.  Currently, Build-Depends-Indep isn't useful, and
only Build-Depends is used in practice on our autobuilder
infrastructure (despite it being perfectly capable of handling
and using B-D-I internally).

The reason for this is that we do our building using dpkg-buildpackage,
and while binary-arch and binary-indep are required targets used by
dpkg-buildpackage, the corresponding build-arch and build-indep targets
are not required and are not used by dpkg-buildpackage at present.

There's some history to this in #374029.  Most of the information
about sbuild/buildds in there is outdated and incorrect.  The only
sticking point to using Build-Depends-Indep and autobuilding
arch-all packages is the lack of support for build-arch and build-all
in dpkg-buildpackage.

Simply enabling this in dpkg-buildpackage would cause widespread
breakage.  build-arch and build-indep have been suggested in Policy
for some time, and they are used by a low percentage of the archive
at present (<400 packages), while 50% of the archive uses dh or
cdbs rules which would allow trivial support in all those packages
once the tools are updated.

I'd like to propose that build-arch and build-indep be changed in
Policy from "may be provided" to "must be provided" in preparation
for enabling their use.  We've wanted to fix the root problem for
at least half a decade, and I'd like to get it done for wheezy.

This should probably also be accompanied by a new lintian check which
can warn if these rules are missing.

Note, this patch obviates the need for the patch in #601839.


Regards,
Roger

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-2-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base                      0.8.20     utilities to manage online documen

-- no debconf information

[policy-build-rules.patch (text/x-diff, attachment)]

Message #10 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: build-arch and build-indep targets are required

Date: Sun, 21 Nov 2010 21:54:33 +0000

[Message part 1 (text/plain, inline)]

On Sun, Nov 21, 2010 at 09:38:31PM +0000, Roger Leigh wrote:
> There's some history to this in #374029.  Most of the information
> about sbuild/buildds in there is outdated and incorrect.  The only
> sticking point to using Build-Depends-Indep and autobuilding
> arch-all packages is the lack of support for build-arch and build-all
> in dpkg-buildpackage.

s/build-all/build-indep/


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@debian.org>

To: Roger Leigh <rleigh@debian.org>, 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: build-arch and build-indep targets are required

Date: Mon, 22 Nov 2010 00:45:28 +0100

* Roger Leigh <rleigh@debian.org>, 2010-11-21, 21:38:
>Currently, Build-Depends-Indep isn't useful,

I've heard this many times, but this is not true. B-D-I is useful and 
many packages use it successfully.

>I'd like to propose that build-arch and build-indep be changed in
>Policy from "may be provided" to "must be provided" in preparation
>for enabling their use.  We've wanted to fix the root problem for
>at least half a decade, and I'd like to get it done for wheezy.

The only source packages that could possibly benefit from
build/build-arch/build-indep separation are those which build at least 
one arch:all package and at least one non-arch:all package. How about 
making the additional target obligatory only for them? If I calculated 
correctly that would reduce number of source packages affected by this 
transition from ~15K to ~2K.

>This should probably also be accompanied by a new lintian check which
>can warn if these rules are missing.

I think we should be changing policy only after the lintian check is 
implement and the majority of packages are fixed.

-- 
Jakub Wilk

Message #20 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Jakub Wilk <jwilk@debian.org>, 604397@bugs.debian.org

Cc: Roger Leigh <rleigh@debian.org>

Subject: Re: Bug#604397: debian-policy: build-arch and build-indep targets are required

Date: Mon, 22 Nov 2010 23:18:43 +0000

[Message part 1 (text/plain, inline)]

On Mon, Nov 22, 2010 at 12:45:28AM +0100, Jakub Wilk wrote:
> * Roger Leigh <rleigh@debian.org>, 2010-11-21, 21:38:
>> I'd like to propose that build-arch and build-indep be changed in
>> Policy from "may be provided" to "must be provided" in preparation
>> for enabling their use.  We've wanted to fix the root problem for
>> at least half a decade, and I'd like to get it done for wheezy.
>
> The only source packages that could possibly benefit from
> build/build-arch/build-indep separation are those which build at least  
> one arch:all package and at least one non-arch:all package. How about  
> making the additional target obligatory only for them? If I calculated  
> correctly that would reduce number of source packages affected by this  
> transition from ~15K to ~2K.

That would make sense.  However, it should be noted that current
Policy requires binary-arch and binary-indep irrespective of if
any arch or indep packages are built, and it would be consistent
to require the same of the corresponding build targets.

>> This should probably also be accompanied by a new lintian check which
>> can warn if these rules are missing.
>
> I think we should be changing policy only after the lintian check is  
> implement and the majority of packages are fixed.

OK.

Just for the record, I've implemented support in debhelper's dh
command in #604563.  Once applied, this will automatically add support
to the huge chunk of the archive using "tiny" rules files.  cdbs will
be next on my list.  These two combined are, by a crude estimate,
grepping the lintian lab, approximately 50% of the total.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Roger Leigh <rleigh@codelibre.net>

Cc: Jakub Wilk <jwilk@debian.org>, 604397@bugs.debian.org, Roger Leigh <rleigh@debian.org>, 229357@bugs.debian.org

Subject: Re: debian-policy: require build-arch and build-indep targets

Date: Tue, 1 Mar 2011 21:01:31 -0600

user debian-policy@packages.debian.org
usertags 604397 + normative discussion
quit

(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,

Roger Leigh wrote:
[out of order for convenience]

> Just for the record, I've implemented support in debhelper's dh
> command in #604563.  Once applied, this will automatically add support
> to the huge chunk of the archive using "tiny" rules files.  cdbs will
> be next on my list.

debhelper 8.1.0 has such support now.  Thanks!

>> * Roger Leigh <rleigh@debian.org>, 2010-11-21, 21:38:

>>> I'd like to propose that build-arch and build-indep be changed in
>>> Policy from "may be provided" to "must be provided" in preparation
>>> for enabling their use.

Personally, I'm all for it; ideally it would happen in the following
order:

 1. Providing build-arch and build-indep becomes a best practice.
    lintian gains a check.  devref encourages the practice.

 2. Becomes a policy "should".

 3. Becomes a policy "must".

That sounds slow, no?  Yes, that's the point.  I'd like to propose
that we not make most of the packages in the archive instantly RC
buggy, today.

>>> We've wanted to fix the root problem for
>>> at least half a decade, and I'd like to get it done for wheezy.

I just noticed this gem in policy §4.9:

	If one or both of the targets build-arch and build-indep are
	not provided, then invoking debian/rules with one of the
	not-provided targets as arguments should produce a exit status
	code of 2.  Usually this is provided automatically by make if
	the target is missing.

So it seems to me that "dpkg-buildpackage -B" ought to be taught to
run the equivalent of

	debian/rules build-arch
	if test "$?" = 2
	then
		debian/rules build
	fi

.  In http://bugs.debian.org/72335 the only argument against that I
see is

	(and notwithstanding that we're going to require both or neither), it
	should say that "debian/rules -q with one of the not-provided targets
	...", because the programs which will want to test this are likely to
	do something cheap like:

	debian/rules -q build-arch
	if [ $? -eq 2 ]; then
	    debian/rules build
	else
	    debian/rules build-arch
	fi

	To try a full build only to receive an exit status of 2 would not say
	whether the build failed or the target was not found.

That doesn't seem so compelling to me; in the failure case, the
autobuilder would just try to pick up where it left off and fail
again, which doesn't sound so expensive.  What am I missing?

Thanks for moving this forward.

Regards,
Jonathan

Message #30 received at 604397@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Wed, 2 Mar 2011 09:59:40 +0100

* Jonathan Nieder <jrnieder@gmail.com> [110302 04:03]:
> I just noticed this gem in policy §4.9:
>
> 	If one or both of the targets build-arch and build-indep are
> 	not provided, then invoking debian/rules with one of the
> 	not-provided targets as arguments should produce a exit status
> 	code of 2.  Usually this is provided automatically by make if
> 	the target is missing.

That was one of the many tries to get somewherewhere without making
non-caring packages buggy. Those attempts have cost us more than 10 years
with no result at all.

> That doesn't seem so compelling to me; in the failure case, the
> autobuilder would just try to pick up where it left off and fail
> again, which doesn't sound so expensive.  What am I missing?

If build is simply a call to a well-behaved make-file, you are right.
Sadly well-behaved upstream build systems are not the norm, and the
more expensive a package get, the bigger it usually is and thus the
more likely something fails in this regard.
In some cases that might even be the fault of debian/rules: one
usually has to do some preparations before calling make. If those
are properly guarded by dependencies on some files (and nothing
making those rules phony, as commonly misused patch rules often do),
this problem can be worked around. But that does not help if upstream's
build system does not behave well.

	Bernhard R. Link

Message #35 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@debian.org>

To: debian-policy@lists.debian.org, 604397@bugs.debian.org, 229357@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Wed, 2 Mar 2011 10:43:24 +0100

* Jonathan Nieder <jrnieder@gmail.com>, 2011-03-01, 21:01:
>So it seems to me that "dpkg-buildpackage -B" ought to be taught to
>run the equivalent of
>
>	debian/rules build-arch
>	if test "$?" = 2
>	then
>		debian/rules build
>	fi

make exits with code 2 "if any errors were encountered". So no, this 
approach cannot be used.

-- 
Jakub Wilk

Message #40 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 604397@bugs.debian.org

Subject: Re: debian-policy: require build-arch and build-indep targets

Date: Wed, 2 Mar 2011 03:59:43 -0600

(-cc: Bug#229357)
Jakub Wilk wrote:
> * Jonathan Nieder <jrnieder@gmail.com>, 2011-03-01, 21:01:

>> So it seems to me that "dpkg-buildpackage -B" ought to be taught to
>> run the equivalent of
>>
>>	debian/rules build-arch
>>	if test "$?" = 2
>>	then
>>		debian/rules build
>>	fi
>
> make exits with code 2 "if any errors were encountered". So no, this
> approach cannot be used.

Did you read the rest of the message?

But okay, I am willing to accept that this is an approach we do
not want to use.  Which still leaves us with a number of options.

To help some existing packages today (and break others):

 1. Find an active "make" maintainer.
 2. Polish the patch in Bug#598534 and apply it.
 3. Use
	make-first-existing-target build-arch build -- -f debian/rules

To help no existing packages today but make it easy for packages
to opt in (and not break the others):

 1. Introduce a Build-Options facility for packages to advertise
    capabilities like this.
 2. Teach dpkg-buildpackage to honor it.

To move towards a world in which all packages support build-arch and
build-indep:

 1. Teach dpkg-buildpackage a new switch to use those targets.
    The operator can easily figure out when they are available if
    building by hand.
 2. Introduce a lintian test for build-arch/build-indep presence.
 3. Contribute patches.
 4. When there are not so many packages left without the feature,
    propose a mass bug-filing/release goal.
 5. Finally, update policy and make autobuilders use the switch
    to use those targets when building unstable and experimental.

Just my two cents,
Jonathan

Message #53 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Fri, 3 Jun 2011 17:09:33 +0100

[Message part 1 (text/plain, inline)]

On Tue, Mar 01, 2011 at 09:01:31PM -0600, Jonathan Nieder wrote:
> Roger Leigh wrote:
> [out of order for convenience]
> 
> > Just for the record, I've implemented support in debhelper's dh
> > command in #604563.  Once applied, this will automatically add support
> > to the huge chunk of the archive using "tiny" rules files.  cdbs will
> > be next on my list.
> 
> debhelper 8.1.0 has such support now.  Thanks!

With dh and cdbs both supporting build-arch and build-indep automatically,
we are now in the situation that >50% of the archive supports these rules.

Is there any reason we can't now make build-arch and build-indep a "should"
in policy?

> >> * Roger Leigh <rleigh@debian.org>, 2010-11-21, 21:38:
> 
> >>> I'd like to propose that build-arch and build-indep be changed in
> >>> Policy from "may be provided" to "must be provided" in preparation
> >>> for enabling their use.
> 
> Personally, I'm all for it; ideally it would happen in the following
> order:
> 
>  1. Providing build-arch and build-indep becomes a best practice.
>     lintian gains a check.  devref encourages the practice.

I wrote a lintian check which is currently in a patch proposed as lintian
bug #605012.  I'm not sure if it needs to be in Policy before or after
it's implemented in lintian?  I thought lintian reflected policy for the
most part.

It probably needs a little more polish (testsuite support) before it can
be applied, but the core checks are done.

>  2. Becomes a policy "should".
> 
>  3. Becomes a policy "must".
> 
> That sounds slow, no?  Yes, that's the point.  I'd like to propose
> that we not make most of the packages in the archive instantly RC
> buggy, today.

Agreed.  Having lintian point out all the packages that are buggy would
be very useful.  We can wait until the majority of packages implement
the new rules before making it an RC-buggy "must".

Is there any recent work on the rules checking in make which would allow
dpkg-buildpackage to use the rules if present, but fall back to build
if absent?  This would be the most pragmatic approach, because it will
both provide backwards compatibility with all older source packages, and
use the rules if present in new ones.


Regards,
Roger
-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Roger Leigh <rleigh@codelibre.net>, 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Fri, 3 Jun 2011 20:25:11 -0700

[Message part 1 (text/plain, inline)]

On Fri, Jun 03, 2011 at 05:09:33PM +0100, Roger Leigh wrote:
> > > Just for the record, I've implemented support in debhelper's dh
> > > command in #604563.  Once applied, this will automatically add support
> > > to the huge chunk of the archive using "tiny" rules files.  cdbs will
> > > be next on my list.

> > debhelper 8.1.0 has such support now.  Thanks!

> With dh and cdbs both supporting build-arch and build-indep automatically,
> we are now in the situation that >50% of the archive supports these rules.

> Is there any reason we can't now make build-arch and build-indep a "should"
> in policy?

How does adding this to policy help us get to the point where we're willing
to turn on use of build-arch on the buildds?

I don't think a policy "should" actually moves us down that road, because
there's no actual penalty for not complying.  The issue is *not* that
maintainers don't, in general, implement this target (in fact, it's been
around forever in the dh_make templates), the issue is that we have no way
of making use of it without a painful transition where lots of packages will
FTBFS, and it's hard even to know which packages those are without trying to
build them.

If people want to track those packages down and NMU them today, they don't
need a policy "should" to do so.  Nor is a policy "should" likely to make
the set of packages in need of an NMU for this any smaller.

If we're willing to flip the switch on the autobuilders and force
maintainers to deal with the breakage, we don't need a policy "should"
either... we can go straight to a policy "must" as soon as the switch is
flipped (and we should flip that switch *ASAP*, not let this question drag
on any further into the release cycle).

And if we want to provide a smooth transition instead, using something like
Joey's proposed make-first-existing-target interface in bug #598534 (as
discussed on debian-devel in
http://lists.debian.org/debian-devel/2010/09/msg00704.html), we don't need
this to be a policy "should" or "must" at all, because the autobuilders can
then DTRT for any package whether or not it implements the build-arch target
and the presence of the target merely lets us optimize build times and
reduce build dependencies - so it could remain a policy "may" indefinitely
(with some tightening of the language about how not having build-arch
requires different bits to be in Build-Depends than if you do have it).

> >  1. Providing build-arch and build-indep becomes a best practice.
> >     lintian gains a check.  devref encourages the practice.

> I wrote a lintian check which is currently in a patch proposed as lintian
> bug #605012.  I'm not sure if it needs to be in Policy before or after
> it's implemented in lintian?  I thought lintian reflected policy for the
> most part.

> It probably needs a little more polish (testsuite support) before it can
> be applied, but the core checks are done.

Unfortunately I see the same problem with this lintian check as with all the
rest - if we can actually check for the existence of the target *reliably*,
then we don't need to enforce its presence at all.

> Is there any recent work on the rules checking in make which would allow
> dpkg-buildpackage to use the rules if present, but fall back to build
> if absent?  This would be the most pragmatic approach, because it will
> both provide backwards compatibility with all older source packages, and
> use the rules if present in new ones.

The patch is outstanding; the make maintainer is TTBOMK currently
unavailable for Debian work.  If there's a consensus on
debian-policy/devel/ctte that we should go the make-first-existing-target
route, I would be more than happy to do an NMU of make to facilitate this.

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

[signature.asc (application/pgp-signature, inline)]

Message #63 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Steve Langasek <vorlon@debian.org>, 604397@bugs.debian.org

Cc: Roger Leigh <rleigh@codelibre.net>

Subject: Re: debian-policy: require build-arch and build-indep targets

Date: Fri, 3 Jun 2011 23:32:13 -0500

Steve Langasek wrote:

> I don't think a policy "should" actually moves us down that road, because
> there's no actual penalty for not complying.  The issue is *not* that
> maintainers don't, in general, implement this target (in fact, it's been
> around forever in the dh_make templates),

As a counterexample, I did not implement the target in any packages I
worked on unless they actually could benefit from the
build-arch/build-indep distinction.  There was simply no obvious
reason to do it, and the documentation gave no hint that it was a good
idea.  The devref would be a better place to put that suggestion given
the current state of things, but to say that documenting it somewhere
would accomplish nothing seems like overstating things.

> the issue is that we have no way
> of making use of it without a painful transition where lots of packages will
> FTBFS, and it's hard even to know which packages those are without trying to
> build them.

Agreed, of course.  The obvious naïve conclusions are:

 1. dpkg-buildpackage could benefit from a new commandline option for
    people to use to test the build-arch/build-indep targets *without*
    changing the behavior on autobuilders, and

 2. autobuilders could benefit from a Build-Options for maintainers to
    declare that it is safe to use the build-arch/build-indep targets
    today.

But see below.

> If we're willing to flip the switch on the autobuilders and force
> maintainers to deal with the breakage, we don't need a policy "should"
> either... we can go straight to a policy "must" as soon as the switch is
> flipped (and we should flip that switch *ASAP*, not let this question drag
> on any further into the release cycle).

Flipping that switch would imho be a bad idea in the current release
cycle anyway.  It's a huge change.

> And if we want to provide a smooth transition instead, using something like
> Joey's proposed make-first-existing-target interface in bug #598534 (as
> discussed on debian-devel in
> http://lists.debian.org/debian-devel/2010/09/msg00704.html)

I was about to say: without a full archive rebuild there is no
guarantee that that would actually provide a smooth transition,
either, since the build-arch targets are not well tested in isolation.
But that was misguided of me:

Assuming that the "build" target depends on "build-arch" and
"build-indep" and does nothing for itself, the most frightening
obvious case is a package that does too little in build-arch, relying
on build-indep to generate some other files (e.g., manpages) that are
needed for binary-arch.  Typically binary-arch would depend on build
in that case, so while breakage of this kind is possible, I don't
imagine it would be widespread.

So I'm all for this.  A test rebuild would still be comforting, of
course.

> The patch is outstanding; the make maintainer is TTBOMK currently
> unavailable for Debian work.  If there's a consensus on
> debian-policy/devel/ctte that we should go the make-first-existing-target
> route, I would be more than happy to do an NMU of make to facilitate this.

Thanks much!  If you'd like, I can try out the two patches from
Bug#598534 and send a comparison there.

By the way, shouldn't the make package be orphaned to reflect the
current reality?  Totally unrelated to the above, I would like to work
with the maintainer to see the latest upstream version of "make"
packaged in experimental, but for a while now the maintainer has been
hard to reach.

Message #68 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: debian-policy@lists.debian.org, 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Sat, 04 Jun 2011 11:45:17 -0700

"Bernhard R. Link" <brlink@debian.org> writes:
> * Steve Langasek <vorlon@debian.org> [110604 05:27]:

>> If we're willing to flip the switch on the autobuilders and force
>> maintainers to deal with the breakage, we don't need a policy "should"
>> either... we can go straight to a policy "must" as soon as the switch
>> is flipped (and we should flip that switch *ASAP*, not let this
>> question drag on any further into the release cycle).

> Having seen this discussion now for almost a decade with people claiming
> smooth transitions coming really soon, I think this is the only way
> unless someone can actually show something for the buildds working now
> (and not in some months, because it has been months for years now).

Agreed.  I really don't think it would be that big of a deal, particularly
right now early in the release cycle.  We could pick some point where
there aren't a lot of ongoing transitions, give people a few weeks of
advance warning, and throw an NMU party, and we'd be done.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #73 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 604397@bugs.debian.org

Cc: Roger Leigh <rleigh@codelibre.net>

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Sat, 4 Jun 2011 13:45:43 -0700

[Message part 1 (text/plain, inline)]

On Fri, Jun 03, 2011 at 11:32:13PM -0500, Jonathan Nieder wrote:
> > I don't think a policy "should" actually moves us down that road, because
> > there's no actual penalty for not complying.  The issue is *not* that
> > maintainers don't, in general, implement this target (in fact, it's been
> > around forever in the dh_make templates),

> As a counterexample, I did not implement the target in any packages I
> worked on unless they actually could benefit from the
> build-arch/build-indep distinction.  There was simply no obvious
> reason to do it, and the documentation gave no hint that it was a good
> idea.  The devref would be a better place to put that suggestion given
> the current state of things, but to say that documenting it somewhere
> would accomplish nothing seems like overstating things.

I'm saying it won't accomplish enough to be a worthwhile intermediate step,
and want us to get back to figuring out a roadmap that would enable us to
turn on build-arch handling on the buildds this cycle.

> > And if we want to provide a smooth transition instead, using something like
> > Joey's proposed make-first-existing-target interface in bug #598534 (as
> > discussed on debian-devel in
> > http://lists.debian.org/debian-devel/2010/09/msg00704.html)

> I was about to say: without a full archive rebuild there is no
> guarantee that that would actually provide a smooth transition,
> either, since the build-arch targets are not well tested in isolation.
> But that was misguided of me:

> Assuming that the "build" target depends on "build-arch" and
> "build-indep" and does nothing for itself, the most frightening
> obvious case is a package that does too little in build-arch, relying
> on build-indep to generate some other files (e.g., manpages) that are
> needed for binary-arch.  Typically binary-arch would depend on build
> in that case, so while breakage of this kind is possible, I don't
> imagine it would be widespread.

> So I'm all for this.  A test rebuild would still be comforting, of
> course.

Given that you seem to have argued in this same mail for providing both an
intermediate dpkg-buildpackage switch, and introducing a Build-Options field
that would have to be populated manually, I'm a little unclear: do you think
make-first-existing-target is a sufficient solution for the buildds, or not?
If you don't think it is, can you point to any problems with the
implementation?

> > The patch is outstanding; the make maintainer is TTBOMK currently
> > unavailable for Debian work.  If there's a consensus on
> > debian-policy/devel/ctte that we should go the make-first-existing-target
> > route, I would be more than happy to do an NMU of make to facilitate this.

> Thanks much!  If you'd like, I can try out the two patches from
> Bug#598534 and send a comparison there.

Thanks for the offer.  How do you plan to try them out?  Are you proposing a
full-archive rebuild?

> By the way, shouldn't the make package be orphaned to reflect the
> current reality?  Totally unrelated to the above, I would like to work
> with the maintainer to see the latest upstream version of "make"
> packaged in experimental, but for a while now the maintainer has been
> hard to reach.

I think it would be reasonable to let the MIA team know about Manoj's
protracted absence (DevRef 7.4).

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

[signature.asc (application/pgp-signature, inline)]

Message #78 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Steve Langasek <vorlon@debian.org>

Cc: 604397@bugs.debian.org, Roger Leigh <rleigh@codelibre.net>

Subject: Re: debian-policy: require build-arch and build-indep targets

Date: Sat, 4 Jun 2011 16:22:43 -0500

Steve Langasek wrote:

> Given that you seem to have argued in this same mail for providing both an
> intermediate dpkg-buildpackage switch, and introducing a Build-Options field
> that would have to be populated manually, I'm a little unclear: do you think
> make-first-existing-target is a sufficient solution for the buildds, or not?

Sorry, I switched opinions mid-message.  I think make-first-existing-target
is sufficient.

More precisely, what I meant to say was that before I had thought
carefully about it, approaches like Build-Options and so on were
appealing, but after your advice, make-first-existing-target seems like a
much better idea (because simpler and sufficient).

> On Fri, Jun 03, 2011 at 11:32:13PM -0500, Jonathan Nieder wrote:

>> Thanks much!  If you'd like, I can try out the two patches from
>> Bug#598534 and send a comparison there.
>
> Thanks for the offer.  How do you plan to try them out?  Are you proposing a
> full-archive rebuild?

I am just going to try to break them.  Cases like these:

 A.
	%:
		dh $@

 B.
	build clean install binary-arch binary-indep binary:
		dh $@
	.PHONY: build-arch build-indep

 C. something using cdbs

 E.
	... typical debian/rules, plus:

	build-indep:
		false

Meanwhile I would be happy to see progress on the dpkg-buildpackage
side.  Once the pieces are together it should be possible to beg someone
to do a full archive rebuild before and after hitting the switch and list
packages that failed to build or whose binary packages changed in size
substantially (though as mentioned before, because "debian/rules
binary-arch" is suppposed to work on its own already, I'm not too worried
about it).

> I think it would be reasonable to let the MIA team know about Manoj's
> protracted absence (DevRef 7.4).

Good idea.  Will do.

Message #83 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 604397@bugs.debian.org, Roger Leigh <rleigh@codelibre.net>

Subject: Re: debian-policy: require build-arch and build-indep targets

Date: Sat, 4 Jun 2011 16:39:19 -0700

On Sat, Jun 04, 2011 at 04:22:43PM -0500, Jonathan Nieder wrote:

> >> Thanks much!  If you'd like, I can try out the two patches from
> >> Bug#598534 and send a comparison there.

> > Thanks for the offer.  How do you plan to try them out?  Are you proposing a
> > full-archive rebuild?

> I am just going to try to break them.  Cases like these:

>  A.
> 	%:
> 		dh $@

>  B.
> 	build clean install binary-arch binary-indep binary:
> 		dh $@
> 	.PHONY: build-arch build-indep

>  C. something using cdbs

>  E.
> 	... typical debian/rules, plus:
> 
> 	build-indep:
> 		false

Ok.  In that case, some of the past discussions may be informative:

  http://lists.debian.org/debian-devel/2007/07/msg00048.html
  http://lists.debian.org/debian-devel/2007/07/msg00113.html

The main difference between the robustness of the implementations should be
when faced with debian/rules that is not a policy-compliant makefile.

> Meanwhile I would be happy to see progress on the dpkg-buildpackage
> side.  Once the pieces are together it should be possible to beg someone
> to do a full archive rebuild before and after hitting the switch and list
> packages that failed to build or whose binary packages changed in size
> substantially (though as mentioned before, because "debian/rules
> binary-arch" is suppposed to work on its own already, I'm not too worried
> about it).

That part is apparently trivial, as I seem to have written a patch for it 4
years ago :-)

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

Message #88 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 604397@bugs.debian.org

Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets

Date: Mon, 6 Jun 2011 09:55:25 +0200

Hi!

On Wed, 2011-03-02 at 03:59:43 -0600, Jonathan Nieder wrote:
> Did you read the rest of the message?
> 
> But okay, I am willing to accept that this is an approach we do
> not want to use.  Which still leaves us with a number of options.
> 
> To help some existing packages today (and break others):
> 
>  1. Find an active "make" maintainer.
>  2. Polish the patch in Bug#598534 and apply it.
>  3. Use
> 	make-first-existing-target build-arch build -- -f debian/rules

Well, I don't think make-first-existing-target belongs in the make
package (but then I'm not the make maintainer). It's clearly a hack,
but if we'd decide this is good enough, then I'd rather see this
supported natively by make itself, which would avoid side-effects
when running make twice (or more), otherwise it might make slightly
more sense to be bolted into dpkg-buildpackage instead.

> To help no existing packages today but make it easy for packages
> to opt in (and not break the others):
> 
>  1. Introduce a Build-Options facility for packages to advertise
>     capabilities like this.
>  2. Teach dpkg-buildpackage to honor it.

I don't think Build-Options/Build-Features is a good idea, as stated
previously on these bug reports. For example most of my packages
already support build-arch/build-indep, now I have to also state that
explicitly? Buh. :)

> To move towards a world in which all packages support build-arch and
> build-indep:
> 
>  1. Teach dpkg-buildpackage a new switch to use those targets.
>     The operator can easily figure out when they are available if
>     building by hand.
>  2. Introduce a lintian test for build-arch/build-indep presence.
>  3. Contribute patches.
>  4. When there are not so many packages left without the feature,
>     propose a mass bug-filing/release goal.
>  5. Finally, update policy and make autobuilders use the switch
>     to use those targets when building unstable and experimental.

And I think we should just go ahead with a flag day and declare
build-arch/build-indep mandatory (at least for the cases were it makes
sense, see below). I'd even go further and combine that with
dpkg-buildpackage stopping to set compilation flags on the environment,
so we only have to deal once with possible mass FTBFS on the archive.

Also not all packages really need them:

  * Source packages that only provide arch:any packages should not have
    Build-Depends-Indep nor Build-Conflicts-Indep, so it should not
    matter if build/binary targets are called directly (instead of
    build-arch/binary-arch).
  * Source packages that only provide arch:all packages might have
    Build-Depends-Indep and Build-Conflicts-Indep, and because they
    have to be satisfied anyway, it does not matter if build/binary
    targets are called directly (instead of build-indep/binary-indep).
  * They really only makes sense for source packages providing both
    arch:any and arch:all packages.

This should reduce the affected packages.

regards,
guillem

Message #93 received at 604397@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 604397@bugs.debian.org, debian-ctte@lists.debian.org

Subject: Request for TC to rule on a course of action for supporting build-arch

Date: Mon, 6 Jun 2011 02:15:37 -0700

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #108 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: 629385@bugs.debian.org

Subject: Re: Request for TC to rule on a course of action for supporting build-arch

Date: Mon, 6 Jun 2011 15:58:06 +0200

Hi,

On Mon, 06 Jun 2011, Steve Langasek wrote:
>  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]

FYI with the recent discussion, Bill Allombert completed the patch
that was supposed to implement this and I just merged it.
See http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef9abc2ce2d394e9ae4d69d4ba68b551620

That said, this should not forbid you to decide that there is a better
way to do it and I'd be happy to merge a patch that changes
dpkg-buildpackage to fallback to some auto-detection mechanism if the flag
is absent.

This would allow maintainers to use those targets without having to
explicitly add the flag.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #113 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 629385@bugs.debian.org

Subject: build-arch: statistics on packages that would be affected by a flag day

Date: Mon, 6 Jun 2011 10:13:23 -0700

[Message part 1 (text/plain, inline)]

This message from Jakub Wilk on debian-policy provides some good information
about the work we'd be facing if we went with a flag day for build-arch:

  http://lists.debian.org/debian-policy/2011/06/msg00018.html

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

[signature.asc (application/pgp-signature, inline)]

Message #116 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 629385@bugs.debian.org

Subject: Re: Request for TC to rule on a course of action for supporting build-arch

Date: Mon, 6 Jun 2011 10:29:09 -0700

On Mon, 06 Jun 2011, Steve Langasek wrote:
>  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'.

From Lucas's test in 2007,[2] "Of those 1823 packages, 31 packages failed
to build. Logs can be found on
http://people.debian.org/~lucas/logs/2007/07/04/ "

Since the logs aren't there anymore, does anyone know what type of
failures were seen with make -qn?


Don Armstrong

2: http://lists.debian.org/debian-devel/2007/07/msg00113.html 
-- 
He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #119 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Andreas Barth <aba@not.so.argh.org>, debian-ctte@lists.debian.org, 604397@bugs.debian.org

Subject: Re: Request for TC to rule on a course of action for supporting build-arch

Date: Mon, 6 Jun 2011 13:20:00 -0700

[Message part 1 (text/plain, inline)]

On Mon, Jun 06, 2011 at 09:56:22PM +0200, Andreas Barth wrote:
> > >  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]

> Option 1 also implies forcing debian/rules to be a Makefile, which is
> think is sensible.

Well, it only implies forcing debian/rules to be a makefile *if the package
wants to benefit from build-arch*.

$ make -f config.sub  -qn build-arch; echo $?
config.sub:61: *** missing separator.  Stop.
2
$

That's sufficient to let dpkg-buildpackage conclude "build-arch is not
supported", falling back to debian/rules build, without stirring up the old
arguments about whether we want to keep Policy 4.9.

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

[signature.asc (application/pgp-signature, inline)]

Message #122 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 629385@bugs.debian.org

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

Date: Mon, 6 Jun 2011 14:44:55 -0700

On Mon, 06 Jun 2011, Lucas Nussbaum wrote:
> On 06/06/11 at 13:35 -0700, Don Armstrong wrote:
> > Happens; do you have any recollection of what the failures were
> > from? [Just trying to make sure that they were failures which were
> > fixable, and not some kind of unforeseen systematic problem.]
> 
> No, sorry; that was almost four years ago!

Ok.

If I was to vote today, I would vote 12543. Implementing another field
to keep in sync seems like a lot of additional work for little gain
(3), and making a slew of packages insta-buggy (4) is not something we
should do. (2) is a nice hack, but it depends too much on undocumented
make behavior.

My primary concern is that there is some kind of systematic problem
with #1 and #2 that we haven't yet considered that affects some
packages. Yet, if we do run into such a problem we can revisit this
discussion.


Don Armstrong

-- 
I made a bunch of stickers
to put on rooftops, and in secret tunnels.
"If you are reading this,
 then you are awesome"
 -- a softer world #569
    http://www.asofterworld.com/index.php?id=569

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #127 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 629385@bugs.debian.org, 604397@bugs.debian.org

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

Date: Mon, 6 Jun 2011 16:02:36 -0700

[Message part 1 (text/plain, inline)]

Hi Bill,

(Sending this to 629385@bugs.debian.org, which is the cloned bug actually
assigned to the TC...)

On Tue, Jun 07, 2011 at 12:06:18AM +0200, Bill Allombert wrote:
> 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.

I think your read that this was a "compromise solution that was agreeable to
everyone" is incorrect.  Scott James Remnant (a dpkg maintainer at the time)
raised in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893#345 the
same objection about fragility that others have raised since.

I'm actually somewhat surprised that this has been merged at all into dpkg,
given that there clearly isn't agreement among the current dpkg maintainers
that this is the right way forward for build-arch.

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

Given that there is zero documentation of what went wrong with the previous
implementation, I give zero weight to that statement from the dpkg
maintainer of the time.  Aside from cases where debian/rules isn't actually
a makefile, I am aware of no potential problems with the patch proposed in
http://lists.debian.org/debian-devel/2007/07/msg00048.html (though I would
probably write that somewhat differently today).  If you can point to a
specific problem with that approach, I would certainly take that into
consideration, but unsubstantiated claims that an approach is "impossible"
are equivalent to FUD.

> Proposal 3 is the safest approach,

It is the most error-prone.

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

[signature.asc (application/pgp-signature, inline)]

Message #132 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: 629385@bugs.debian.org, 604397@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

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

Date: Tue, 7 Jun 2011 09:29:12 +0200

On Mon, Jun 06, 2011 at 04:02:36PM -0700, Steve Langasek wrote:
> Hi Bill,
> 
> (Sending this to 629385@bugs.debian.org, which is the cloned bug actually
> assigned to the TC...)
> 
> On Tue, Jun 07, 2011 at 12:06:18AM +0200, Bill Allombert wrote:
> > 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.
> 
> I think your read that this was a "compromise solution that was agreeable to
> everyone" is incorrect.  Scott James Remnant (a dpkg maintainer at the time)
> raised in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893#345 the
> same objection about fragility that others have raised since.

Scott did not take part in the initial discussion, so there was no way his objection
would be taken into account.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #137 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: 629385@bugs.debian.org, lucas@debian.org

Subject: Re: Request for TC to rule on a course of action for supporting build-arch

Date: Tue, 7 Jun 2011 09:41:18 +0200

[Message part 1 (text/plain, inline)]

(Bcc to debian-dpkg for info)

On Mon, 06 Jun 2011, Steve Langasek 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]
> 
>  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

I suggest a supplementary option that combines 4 and 1. And I attach the
corresponding dpkg patch.

---
Turn on direct use of "debian/rules build-arch" unless the package seems
to be missing the target according to "make -qn". In that case output a
warning that asks the packager to implement the required targets, but
fallback to using the "build" target.

The fallback to build and the "make -qn" auto-detection is temporary to
ease the transition but should dropped at some point (wheezy+1, or
wheezy+2). The policy should document that the targets must be supported.
---

Lucas, can you do a full rebuild with the packages below ?
http://people.debian.org/~hertzog/packages/dpkg-dev_1.16.1~buildarch.1_all.deb
http://people.debian.org/~hertzog/packages/libdpkg-perl_1.16.1~buildarch.1_all.deb

You should use a binary-only build (i.e. dpkg-buildpackage -B or -A for
packages which are arch: all).

I would like to know if it introduces new build failures, and
also how many packages have this warning:
dpkg-buildpackage: warning: debian/rules must be updated to support the 'build-arch' and 'build-indep' targets (at least 'build-arch' seems to be missing)

grep just on "debian/rules must be updated to support", the parenthesis
can vary between -B and -A. Also you can only see the warning if you use
-B or -A, with -b (the default), you can't generate it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

[patch (text/plain, attachment)]

Message #142 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Russ Allbery <rra@debian.org>, 604397@bugs.debian.org

Cc: debian-ctte@lists.debian.org, 629385@bugs.debian.org

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

Date: Fri, 10 Jun 2011 00:21:24 +0200

On Mon, Jun 06, 2011 at 01:04:59PM -0700, Russ Allbery wrote:
> Andreas Barth <aba@not.so.argh.org> writes:
> 
> > Option 1 also implies forcing debian/rules to be a Makefile, which is
> > think is sensible.
> 
> Policy already requires this.  The only package in the archive for which
> this is not already the case is "leave".
> 
> I don't like option #3 because it's something we'll be stuck with forever
> and requires packagers update both debian/rules and debian/control to
> configure things properly.  One of the reasons why I'm personally fond of
> #4 is that it reduces our long-term complexity.  #3 increases our
> long-term complexity, I think unnecessarily.

I have proposed an alternative in the past (which did not get any support, though):
Decide that packages that have a Build-Depends-Indep: field must implement
build-arch/build-indep. This is probably already the case.

This has the same advantage than Build-Options: a program can check if dpkg-buildpackage
will call build-arch just by looking at the control file.

There should be a well-defined interface to know whether dpkg-buildpackage will
call build-arch or build, that does not depend on a specific dpkg-buildpackage 
implementation. I am afraid that any makefile trickery would not be stable enough
for that purpose.

Concerning the long-term complexity: If you look at the bug log, you will see
that developpers objected that the build-arch/build-indep split was unnecessary
complexity for packages that would not get any benefit of it, so Build-Options was
proposed which allowed the split to be optional (so only packages that get some
benefit of it would have to implement it).

(PS: I am unsure how this bug fit the purpose of the TC. There is only one
alternative that have been implemented or even drafted at this stage.)

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

Message #147 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

Cc: 604397@bugs.debian.org, debian-ctte@lists.debian.org, 629385@bugs.debian.org

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

Date: Thu, 09 Jun 2011 15:28:43 -0700

Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:

> I have proposed an alternative in the past (which did not get any
> support, though):  Decide that packages that have a Build-Depends-Indep:
> field must implement build-arch/build-indep. This is probably already
> the case.

> This has the same advantage than Build-Options: a program can check if
> dpkg-buildpackage will call build-arch just by looking at the control
> file.

This is a hack, though, that relies on the assumption that any package
with separate build-arch and build-indep targets will have additional
dependencies for build-indep.  This is not necessarily true.  For example,
building architecture-independent bearoff databases for GnuBG doesn't
require any additional packages.

> There should be a well-defined interface to know whether
> dpkg-buildpackage will call build-arch or build, that does not depend on
> a specific dpkg-buildpackage implementation.

I don't agree with this statement in the long run.  I don't see any reason
not to have a goal of having dpkg-buildpackage call build-arch
unconditionally.  The most maintainable, most easily testable, and least
complex way to implement an option in a software system is to not make it
an option.

My goal is to allow everyone developing for Debian three years from now to
not care that this debate ever happened.

> Concerning the long-term complexity: If you look at the bug log, you
> will see that developpers objected that the build-arch/build-indep split
> was unnecessary complexity for packages that would not get any benefit
> of it, so Build-Options was proposed which allowed the split to be
> optional (so only packages that get some benefit of it would have to
> implement it).

I think that the dh program and its widespread adoption has mostly made
that objection obsolete.  For those who are still listing separate targets
in debian/rules, making build-arch and build-indep just depend on build is
not generally difficult.

> (PS: I am unsure how this bug fit the purpose of the TC. There is only
> one alternative that have been implemented or even drafted at this
> stage.)

The TC is currently considering four different options, all of which are
either already implemented or fairly easy to implement in a short time
frame.  I don't think all the options have to be at the point of being
appliable patches before the TC can consider something.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #154 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 629385@bugs.debian.org

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

Date: Sat, 11 Jun 2011 16:07:09 -0700

[Message part 1 (text/plain, inline)]

On Tue, Jun 07, 2011 at 09:41:18AM +0200, Raphael Hertzog wrote:
> On Mon, 06 Jun 2011, Steve Langasek 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]

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

> I suggest a supplementary option that combines 4 and 1. And I attach the
> corresponding dpkg patch.

> ---
> Turn on direct use of "debian/rules build-arch" unless the package seems
> to be missing the target according to "make -qn". In that case output a
> warning that asks the packager to implement the required targets, but
> fallback to using the "build" target.

> The fallback to build and the "make -qn" auto-detection is temporary to
> ease the transition but should dropped at some point (wheezy+1, or
> wheezy+2). The policy should document that the targets must be supported.
> ---

This actually reads to me the same as option 1.  What distinction are you
meaning to draw here?  It's not very "direct" use of build-arch if we're
checking 'make -qn' first.  The only other differences I see here are
issuing a warning, and explicitly declaring to put this in policy now and
that the auto-detection will eventually be deprecated.  To me these all seem
like implementation details that don't need to be ruled on in order for the
TC to make its decision, but I'm also happy to have these spelled out in
option 1 if that's the consensus.

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

[signature.asc (application/pgp-signature, inline)]

Message #159 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 629385@bugs.debian.org

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

Date: Sun, 12 Jun 2011 08:24:11 +0200

On Sat, 11 Jun 2011, Steve Langasek wrote:
> This actually reads to me the same as option 1.  What distinction are you
> meaning to draw here?  It's not very "direct" use of build-arch if we're
> checking 'make -qn' first.  The only other differences I see here are
> issuing a warning, and explicitly declaring to put this in policy now and
> that the auto-detection will eventually be deprecated.  To me these all seem
> like implementation details that don't need to be ruled on in order for the
> TC to make its decision, but I'm also happy to have these spelled out in
> option 1 if that's the consensus.

As a dpkg co-maintainer, the implementation details matter to me. :-)

More seriously, the distinction I see is that with your option 1, it seems
like auto-detection ought be _always_ used in the future and that it's
perfectly fine to have only some packages implement
build-arch/build-indep.

I believe that auto-detection is a hack and to me it's only acceptable as
a temporary measure (i.e. until all packages support build-arch/build-indep).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #164 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: 629385@bugs.debian.org, 604397@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

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

Date: Thu, 30 Jun 2011 23:34:28 +0200

On Tue, Jun 07, 2011 at 09:29:12AM +0200, Bill Allombert wrote:
> On Mon, Jun 06, 2011 at 04:02:36PM -0700, Steve Langasek wrote:
> > Hi Bill,
> > 
> > (Sending this to 629385@bugs.debian.org, which is the cloned bug actually
> > assigned to the TC...)

Too much magic, but thanks anyway.

> > On Tue, Jun 07, 2011 at 12:06:18AM +0200, Bill Allombert wrote:
> > > 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.
> > 
> > I think your read that this was a "compromise solution that was agreeable to
> > everyone" is incorrect.  Scott James Remnant (a dpkg maintainer at the time)
> > raised in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893#345 the
> > same objection about fragility that others have raised since.

Scott was not yet the dpkg maintainer when the discussion occurred.

> Scott did not take part in the initial discussion, so there was no way his objection
> would be taken into account.

... but Scott has been the maintainer of dpkg for a sufficiently long time to
implement autodetection if he wanted to, but he did not manage to do it.

And that is the major reason I not impressed by autodetection: it is proposed
every few year as the silver bullet to fix that issue, but it never materialize
while putting the other options to the backburner, and only fix half of the problem
(packages still have to be changed to split Build-Depends-Indep from Build-Depends).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #169 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 629385@bugs.debian.org

Subject: Re: Bug#629385: Request for TC to rule on a course of action for, supporting build-arch

Date: Sun, 30 Oct 2011 19:22:44 +0100

Hi,

I have a 6th (?) proposal.

Lintian recently got checks for finding packages without build-arch and
build-indep targets.  Currently it finds some 5600 packages and with the
current rate it will take nearly 2 years to fix all of them.

As pointed out earlier, only packages building both arch:all and
non-arch:all packages benefit from this.  With this in mind, we can
"trivially" create a new lintian tag that finds source packages building
arch:all + non-arch:all packages without build-{arch,indep} targets.

My proposal is, implement the above mentioned lintian tag and make a
release goal focusing on fixing all packages emitting this tag.
Basically this is a weaker version of (4) and we can start on it now
without hardly any consequences.
  Should a better solution be chosen before we are done with fixing
these packages, we can trivially cancel the release goal and remove the
lintian tag.  Particularly, we are not left with a lot of RC buggy
packages nor will we have a new field that suddenly became redundant etc.

~Niels

Message #174 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Niels Thykier <niels@thykier.net>

Cc: 629385@bugs.debian.org

Subject: Re: Bug#629385: Request for TC to rule on a course of action for, supporting build-arch

Date: Sun, 30 Oct 2011 11:30:55 -0700

Niels Thykier <niels@thykier.net> writes:

> As pointed out earlier, only packages building both arch:all and
> non-arch:all packages benefit from this.  With this in mind, we can
> "trivially" create a new lintian tag that finds source packages building
> arch:all + non-arch:all packages without build-{arch,indep} targets.

> My proposal is, implement the above mentioned lintian tag and make a
> release goal focusing on fixing all packages emitting this tag.
> Basically this is a weaker version of (4) and we can start on it now
> without hardly any consequences.
>   Should a better solution be chosen before we are done with fixing
> these packages, we can trivially cancel the release goal and remove the
> lintian tag.  Particularly, we are not left with a lot of RC buggy
> packages nor will we have a new field that suddenly became redundant
> etc.

I certainly don't see any drawbacks to doing this independent of whatever
else is going on.  It won't hurt, and it could very well make any
long-term solution to the problem easier.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #179 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 629385@bugs.debian.org, debian-dpkg@lists.debian.org

Subject: Re: Request for TC to rule on a course of action for supporting build-arch

Date: Sat, 17 Mar 2012 18:15:45 -0700

I believe that the discussion of this has reached a conclusion and the
dpkg maintainers are moving forward with an implementation.  At this
point, it seems like the right thing for the Technical Committee to do is
to affirm that we agree with the approach arrived at.

I propose the following ballot:

A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
   the package with "make -qn" to see if the build-arch target appears to
   be implemented.  If so, it should use "debian/rules build-arch" to
   build the package instead of "debian/rules build".  If it detects via
   "make -qn" that the target is missing, it should output a warning
   asking the packager to implement the required targets, and then fall
   back to using "debian/rules build".

   The fallback to "debian/rules build" and the "make -qn" auto-detection
   are temporary to ease the transition but should be dropped at some
   point (wheezy+1, or wheezy+2).

   Debian Policy should be updated to make build-arch and build-indep
   mandatory targets.

B. Further discussion

Please send any wording changes to the above, or any other options that
you believe should be on the ballot.  If there are no objections, I plan
to call for a vote in a few days.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #184 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 629385@bugs.debian.org

Cc: debian-dpkg@lists.debian.org

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

Date: Tue, 20 Mar 2012 13:33:05 -0700

Hearing no objections, I call for a TC vote on the following ballot:

A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
   the package with "make -qn" to see if the build-arch target appears to
   be implemented.  If so, it should use "debian/rules build-arch" to
   build the package instead of "debian/rules build".  If it detects via
   "make -qn" that the target is missing, it should output a warning
   asking the packager to implement the required targets, and then fall
   back to using "debian/rules build".

   The fallback to "debian/rules build" and the "make -qn" auto-detection
   are temporary to ease the transition but should be dropped at some
   point (wheezy+1, or wheezy+2).

   Debian Policy should be updated to make build-arch and build-indep
   mandatory targets.

B. Further discussion

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #189 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 629385@bugs.debian.org

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

Date: Tue, 20 Mar 2012 13:49:47 -0700

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> writes:

> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>    the package with "make -qn" to see if the build-arch target appears to
>    be implemented.  If so, it should use "debian/rules build-arch" to
>    build the package instead of "debian/rules build".  If it detects via
>    "make -qn" that the target is missing, it should output a warning
>    asking the packager to implement the required targets, and then fall
>    back to using "debian/rules build".

>    The fallback to "debian/rules build" and the "make -qn" auto-detection
>    are temporary to ease the transition but should be dropped at some
>    point (wheezy+1, or wheezy+2).

>    Debian Policy should be updated to make build-arch and build-indep
>    mandatory targets.

> B. Further discussion

I vote AB.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[Message part 2 (application/pgp-signature, inline)]

Message #194 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 629385@bugs.debian.org

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

Date: Tue, 20 Mar 2012 14:03:49 -0700

On Tue, 20 Mar 2012, Russ Allbery wrote:
> Hearing no objections, I call for a TC vote on the following ballot:
> 
> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>    the package with "make -qn" to see if the build-arch target appears to
>    be implemented.  If so, it should use "debian/rules build-arch" to
>    build the package instead of "debian/rules build".  If it detects via
>    "make -qn" that the target is missing, it should output a warning
>    asking the packager to implement the required targets, and then fall
>    back to using "debian/rules build".
> 
>    The fallback to "debian/rules build" and the "make -qn" auto-detection
>    are temporary to ease the transition but should be dropped at some
>    point (wheezy+1, or wheezy+2).
> 
>    Debian Policy should be updated to make build-arch and build-indep
>    mandatory targets.
> 
> B. Further discussion

I vote AB.


Don Armstrong

-- 
Logs drowse in the pond
Dreaming of their heroes
Alligator and crocodile
 -- Vern Rutsala "Poetry in Motion" p77

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #199 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 629385@bugs.debian.org

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

Date: Tue, 20 Mar 2012 23:10:14 +0000

Russ Allbery writes ("Bug#629385: Request for TC to rule on a course of action for supporting build-arch"):
> Hearing no objections, I call for a TC vote on the following ballot:
> 
> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>    the package with "make -qn" to see if the build-arch target appears to
>    be implemented.  If so, it should use "debian/rules build-arch" to
>    build the package instead of "debian/rules build".  If it detects via
>    "make -qn" that the target is missing, it should output a warning
>    asking the packager to implement the required targets, and then fall
>    back to using "debian/rules build".
> 
>    The fallback to "debian/rules build" and the "make -qn" auto-detection
>    are temporary to ease the transition but should be dropped at some
>    point (wheezy+1, or wheezy+2).
> 
>    Debian Policy should be updated to make build-arch and build-indep
>    mandatory targets.

I still don't like this temporary hack but I don't dislike it enough
to vote against.  So my vote is: abstain.

Thanks,
Ian.

Message #204 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Russ Allbery <rra@debian.org>, 629385@bugs.debian.org, 629385@bugs.debian.org

Cc: debian-dpkg@lists.debian.org

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

Date: Wed, 21 Mar 2012 01:10:53 +0100

<#part sign=pgpmime>
On Tue, 20 Mar 2012 13:33:05 -0700, Russ Allbery <rra@debian.org> wrote:
> Hearing no objections, I call for a TC vote on the following ballot:

I vote AB.

Bdale

Message #209 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 629385@bugs.debian.org

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

Date: Wed, 21 Mar 2012 10:43:47 +0100

* Russ Allbery (rra@debian.org) [120320 21:48]:
> Hearing no objections, I call for a TC vote on the following ballot:
> 
> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>    the package with "make -qn" to see if the build-arch target appears to
>    be implemented.  If so, it should use "debian/rules build-arch" to
>    build the package instead of "debian/rules build".  If it detects via
>    "make -qn" that the target is missing, it should output a warning
>    asking the packager to implement the required targets, and then fall
>    back to using "debian/rules build".
> 
>    The fallback to "debian/rules build" and the "make -qn" auto-detection
>    are temporary to ease the transition but should be dropped at some
>    point (wheezy+1, or wheezy+2).
> 
>    Debian Policy should be updated to make build-arch and build-indep
>    mandatory targets.
> 
> B. Further discussion

I vote AB.


Andi

Message #214 received at 629385-done@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 629385-done@bugs.debian.org

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

Date: Wed, 21 Mar 2012 16:21:58 -0700

On Wed, 21 Mar 2012, Andreas Barth wrote:
> I vote AB.

With the abstention of Ian; the outcome of the vote is no longer in
doubt, and option A is the technical course of option that
dpkg-buildpackage should take:

A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
   the package with "make -qn" to see if the build-arch target appears to
   be implemented.  If so, it should use "debian/rules build-arch" to
   build the package instead of "debian/rules build".  If it detects via
   "make -qn" that the target is missing, it should output a warning
   asking the packager to implement the required targets, and then fall
   back to using "debian/rules build".

   The fallback to "debian/rules build" and the "make -qn" auto-detection
   are temporary to ease the transition but should be dropped at some
   point (wheezy+1, or wheezy+2).

   Debian Policy should be updated to make build-arch and build-indep
   mandatory targets.



Don Armstrong

-- 
It can sometimes happen that a scholar, his task completed, discovers
that he has no one to thank. Never mind. He will invent some debts.
Research without indebtedness is suspect, and somebody must always,
somehow, be thanked.
 -- Umberto Eco "How to Write an Introduction"

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #219 received at 629385@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: 629385@bugs.debian.org

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

Date: Sat, 31 Mar 2012 18:20:25 +0100

[Message part 1 (text/plain, inline)]

On Tue, Mar 20, 2012 at 01:33:05PM -0700, Russ Allbery wrote:
> Hearing no objections, I call for a TC vote on the following ballot:
> 
> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>    the package with "make -qn" to see if the build-arch target appears to
>    be implemented.  If so, it should use "debian/rules build-arch" to
>    build the package instead of "debian/rules build".  If it detects via
>    "make -qn" that the target is missing, it should output a warning
>    asking the packager to implement the required targets, and then fall
>    back to using "debian/rules build".
> 
>    The fallback to "debian/rules build" and the "make -qn" auto-detection
>    are temporary to ease the transition but should be dropped at some
>    point (wheezy+1, or wheezy+2).
> 
>    Debian Policy should be updated to make build-arch and build-indep
>    mandatory targets.
> 
> B. Further discussion

Since this is essentially supporting what the current dpkg maintainers
appear to have decided to do anyway, and I don't think further
discussion will reveal much more, I vote AB (though this may be too
late).

-- 
Colin Watson                                       [cjwatson@debian.org]

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.