Bug#846970: Patch to document Build-Indep-Architecture field
On 2018-06-15 19:05, Sean Whitton wrote:
> 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.
I confirm this is not currently supported by the autobuilders. If it
gets added, we'll add support to respect this field, i.e. not try to
build the package on an autobuilder with a different architecture than
the specified one. That said, we do not plan to add support for
non-amd64 based arch:all autobuilder at this point.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: