I was recently told to split part of my Build-Depends field into a separate Build-Depends-Indep field. Not one to follow orders without question, I went and did some research, and found this snippet in the policy[1]:

"There is no Build-Depends-Arch; this role is essentially met with Build-Depends. Anyone building the build-indep and binary-indep targets is assumed to be building the whole package, and therefore installation of all build dependencies is required.

The assumption confused me at first. For example, one natural distributed build process might be (A):

1. build-indep on a single machine
2. copy the half-built tree to all machines
3. build-arch on all machines

In this case, then clearly it is advantageous to have a separate Build-Depends-Arch. For example, if I am only building docs in (1), I would not want to install all of the -dev dependencies at that stage.

However, thinking about it a bit more, leads me to deduce that the actual build process is something like (B):

1. build (-indep and -arch) on a single machine (perhaps the developer's?)
2. build-arch on all other machines of a different arch

The assumption then makes sense in this context, but for a person not familiar with Debian's build infrastructure, it takes quite some effort to work out.

So, the reason why I originally thought (A) is because I was confused and thought that "build-arch" was simply "do build tasks that are arch-dependent" and the counterpart for "build-indep". Of course, I now realise that this interpretation doesn't make sense because arch-indep vs arch-dep tasks might overlap in the order they need to be run in. So (A) is actually not coherent, but again it takes some effort to work this out.

The more precise definition of "build-arch" from [2] says "The build-arch target must perform all the configuration and compilation required for producing all architecture-dependant binary packages".

If other people are making the similar mistake, it would be useful to add a discussion/debunking of that more "intuitive" interpretation to try to prevent this.

[1] http://www.debian.org/doc/debian-policy/footnotes.html#f55
[2] http://www.debian.org/doc/debian-policy/ch-source.html

user debian-policy@packages.debian.org
usertags 727610 informative issue
severity 727610 wishlist
retitle 727610 debian-policy: update footnote of section 7.7 once the buildds call “binary-arch”.
thanks

Le Thu, Oct 24, 2013 at 03:47:56PM +0100, Ximin Luo a écrit :

Dear Ximin,

in my understanding, it is planned that the autobuilders will call “build-arch”
instead of “build” once enough packages support this target.  According to
Lintian's report, it looks like the goal is near reached.

http://lintian.debian.org/tags/package-would-benefit-from-build-arch-targets.html

I recommend to wait that the behaviour of the autobuilders is changed before
spending some time on the wording.

Have a nice day,

Hi!

Not very near, unfortunately, here's the actual tag:

  <http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html>

See #657390 for more information, regarding possible transition plans.

Thanks,
Guillem

Hi!

dpkg has supported Build-Depends-Arch and Build-Conflicts-Arch since
1.16.4 (complete support with 1.17.0). Although they should not be
used yet, as long as other resolvers are not aware of these.

Thanks,
Guillem

Hi Policy maintainers,

With dpkg and buildds supporting build-arch and build-indep plus source
uploads being tested in unstable, perhaps it is time to move forward
with this again?  :)


The build options are currently:

1. Maintainer uses binary and build targets (i.e. *-arch AND *-indep)
   - buildds uses binary-arch and build-arch missing architectures
2. Maintainer uses binary-indep and build-indep targets
   - buildds uses binary-arch and build-arch on *every* architecture
     (Ben Hutching has been doing this for a while already)
3. Maintainer uploads a source only (*)
   - One buildd uses binary-indep and build-indep to build the arch:all
     packages (if present)
   - buildds uses binary-arch and build-arch on *every* architecture

(*): Being tested in experimental atm.,

As noted, only option 1 uses the binary and build target.

Thanks,
~Niels

Please CC me on replies.