Bug#846970: Patch to document Build-Indep-Architecture field

[Sean Whitton <spwhitton@spwhitton.name>]

control: tag -1 -patch

[CCing those involved in the original discussion, and wanna-build team,
in case they object to my proposal below to just close this bug]

Hello,

On Fri, Jun 15 2018, Ian Jackson wrote:

> Sean Whitton writes ("Bug#846970: Patch to document Build-Indep-Architecture field"):
>> > +``Build-Indep-Architecture``
>> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > +
>> > +Specification of architectures on which the architecture-independent
>> > +binary packages are known to be buildable and/or not buildable.  If
>> > +this field is not specified, it defaults to ``any``, matching all
>> > +Debian machine architectures.  If specified, it should be either
>> > +
>> > +-  A unique single word identifying a Debian machine architecture as
>> > +   described in :ref:`s-arch-spec`.
>> > +
>> > +-  An architecture wildcard identifying a set of Debian machine
>> > +   architectures, see :ref:`s-arch-wildcard-spec`.
>> > +
>> > +This header is useful in the rare case where architecture-independent
>> > +packages cannot be built on all architectures for reasons outside the
>> > +maintainer's control.
>> > +
>> > +Although the syntax of the field permits it, you should avoid
>> > +specifying that the package can be built on only a single
>> > +architecture.  This provides flexibility to the administrators of
>> > +autobuilder infrastructure.
>
> I'm afraid I don't understand this.
>
> AFAICT from reading s-arch-spec and s-arch-wildcard-spec and looking
> at the output of dpkg-architecture -L, the above syntax specification
> permits, with our current arch list, only Build-Indep-Architecture
> field contents of the following four forms:
>
>     amd64              (FSVO amd64)              doc says don't do this
>     kfreebsd-any       (FSVO kfreebsd)           useful but niche
>     kfreebsd-amd64     (FSVO kfreebsd & amd64)   doc says don't do this
>     any-amd64          (FSVO amd64               not very useful
>     any                                          the default
>
> So there is no good use for this field.  

Thank you for this analysis.

My original expectation was that the most common use of the field would
be of the form

    Build-Indep-Architecture: !amd64

but this is not actually permitted by my patch.  Negating architecture
names is described only under the Depends field.  I think that Mattia
had realised this mistake, but I mustn't have read his e-mail carefully
enough, so sorry, all, for being a bit careless.

We can fix my patch in a few different ways:

1. add "an exclamation mark followed by a unique single word identifying
   a Debian machine architecture ..." as one of the possible values

2. add the ability to specify a list of architectures and/or
   architecture wildcards, separated by commas

3. both of the above, (1) and (2)

4. drop the 'should' requirement that the field specify at least two
   architectures.

The main problem with (1), (2) and (3) is that it means a new parser has
to be written for this field, as we will be departing from the syntax of
the Architecture field.

The main problem with (4) has already been discussed: we don't want to
encourage people to just type `Build-Indep-Architecture:
my-laptops-arch` whenever their arch:all package FTBFSs on another arch.

Zooming out a bit:

We do not normally add fields to Policy until they are already in use in
the archive.

Looking at codesearch.debian.net reveals that only a single package is
actually using this field at present.  I haven't checked, but presumably
the field is not supported by the Debian autobuilders.

So I would like to suggest we just close this bug until those who would
actually be involved in implementing support for the field chime in to
say that it is needed, and exactly what's needed.

-- 
Sean Whitton