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
aurel...@aurel32.net http://www.aurel32.net
Bug#846970: Patch to document Build-Indep-Architecture field
On Fri, 2018-06-15 at 19:05:17 +0100, Sean Whitton wrote:
> Sean Whitton writes ("Bug#846970: Patch to document Build-Indep-Architecture
> field"):
> > > +``Build-Indep-Architecture``
> > > +
> 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.
This has been discussed multiple times over the years [D]. I still
consider both the purpose of this field a workaround [W], and its
name to be potentially very confusing [N]. :)
Regarding the name, in addition to what I mention in [N], there's also
the fact that we already have Build--Indep and Build--Arch.
With the second being in a way a poor name, and while not Architecture,
it would make adding Build-Indep-Arch.* less than ideal.
I think a better approach for many of these cases might be
<https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches>, but I'd
otherwise consider the more immediate and realistic cross-compiler
option to be way preferable (even the variant of building the
cross-compiler from within the package itself), than this field.
And I'm saying this as one of the perpetrators that maintained and/or
introduced many of the abominable packaging aberrations that abuse
the Architecture field and semantics in that way, and would need of
something like this. :)
Thanks,
Guillem
[D] <…other earlier discussions omitted…>
<https://lists.debian.org/debian-devel/2011/02/msg00223.html>,
<https://lists.debian.org/debian-devel/2014/02/msg01125.html>.
[W] <https://lists.debian.org/debian-devel/2011/02/msg00534.html>
[N] <https://lists.debian.org/debian-devel/2014/08/msg00810.html>
Bug#846970: Patch to document Build-Indep-Architecture field
Hello Steve, On Fri, Jun 15 2018, Steve Langasek wrote: > Both of the above are real-world examples that I've encountered where > Build-Indep-Architecture would be useful. But I know of no packages > that would benefit from '!amd64' as a specification. > > In the first example, instead of 'i386' it would possibly be useful to > be able to enumerate 32-bit architectures. This would benefit users > who are building (bootstrapping) packages in an archive that doesn't > have i386 as a supported architecture but does have some other 32-bit > architecture available. > > But using '!amd64' for this is unhelpfully inaccurate, since most > systems are 64-bit nowadays and one should not infer that '!amd64' > means 'i386'. Thank you for this input. >> 2. add the ability to specify a list of architectures and/or >>architecture wildcards, separated by commas > > Why commas? Other architecture fields in debian/control are > space-delimited. This was just an oversight on my part. Spaces it is. >> 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. > > I don't see a reason to use the field definition to try to guard > against that. Policy also doesn't prohibit you declaring > Architecture: amd64 for packages that you have failed to port to other > architectures. This is correctly enforced as distro policy, not as > debian/control syntax. Fair enough. I don't think we can proceed without input from the wanna-build team on whether it would be a burden to them to have packages declare their arch:all packgaes can be built on just a single architecture. -- Sean Whitton
Bug#846970: Patch to document Build-Indep-Architecture field
On Fri, Jun 15, 2018 at 07:05:17PM +0100, Sean Whitton wrote: > 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 I can't imagine why anyone would ever actually specify this. A more realistic usage for this field would be: Build-Indep-Architecture: i386 for cases where the bits can only be built on a 32-bit arch; or Build-Indep-Architecture: ppc64el for e.g. cases where you are building firmware bits targeted to POWER and the most reliable way to do that is to build them same-arch instead of build-dependending on cross-compilers. Both of the above are real-world examples that I've encountered where Build-Indep-Architecture would be useful. But I know of no packages that would benefit from '!amd64' as a specification. In the first example, instead of 'i386' it would possibly be useful to be able to enumerate 32-bit architectures. This would benefit users who are building (bootstrapping) packages in an archive that doesn't have i386 as a supported architecture but does have some other 32-bit architecture available. But using '!amd64' for this is unhelpfully inaccurate, since most systems are 64-bit nowadays and one should not infer that '!amd64' means 'i386'. > 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 I really don't think this is a good idea. > 2. add the ability to specify a list of architectures and/or >architecture wildcards, separated by commas Why commas? Other architecture fields in debian/control are space-delimited. > 3. both of the above, (1) and (2) > 4. drop the 'should' requirement that the field specify at least two >architectures. Yes please. > 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. I don't see a reason to use the field definition to try to guard against that. Policy also doesn't prohibit you declaring Architecture: amd64 for packages that you have failed to port to other architectures. This is correctly enforced as distro policy, not as debian/control syntax. -- 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 https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
On Fri, 15 Jun 2018 at 18:16:47 +0100, Ian Jackson wrote: > > > +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`. > I'm afraid I don't understand this. Was the intention that the Build-Indep-Architecture is a space-separated list of words, each of which is an architecture or architecture wildcard as defined above? That would make more sense (and would almost match Architecture in debian/control or in a .dsc file, except that 'all' doesn't make sense here and so is disallowed, which as far as I can work out makes the only difference between those two Architecture fields disappear). I know the intention was "it's the same as Architecture because we already have to know how to parse that", but Architecture has different specifications in debian/control, in a .dsc file, in a .changes file, and in a binary package's DEBIAN/control... smcv
Processed: Re: Bug#846970: Patch to document Build-Indep-Architecture field
Processing control commands: > tag -1 -patch Bug #846970 [debian-policy] debian-policy: Proposal for a Build-Indep-Architecture: control file field Removed tag(s) patch. -- 846970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#846970: Patch to document Build-Indep-Architecture field
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
Bug#846970: Patch to document Build-Indep-Architecture field
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. Furthermore, the things that
people actually want to be able to say ("some x86 machine", "something
mostly 32-bit", "something mostly 64-bit", "not freebsd") are not
expressable.
I think the result is surely going to be that people write "amd64"
because that "makes their thing work", and anyone who complains about
that will be asked by the maintainer to please suggest a better
option.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#846970: Patch to document Build-Indep-Architecture field
Hello, On Thu, Jun 14 2018, Jess Hall wrote: > How about "You should not specify that the packages are buildable on > only one architecture."? This is better than what I wrote, thanks, Jess. Here is the updated and rebased patch for seconding: > policy/ch-controlfields.rst | 27 +++ > 1 file changed, 27 insertions(+) > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index df95d1d..73331f3 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -121,6 +121,8 @@ package) are: > > - :ref:`Build-Depends et al ` > > +- :ref:`Build-Indep-Architecture ` > + > - :ref:`Standards-Version ` (recommended) > > - :ref:`Homepage ` > @@ -1036,6 +1038,31 @@ This field is automatically added to Debian source > control files > field may also be used in source package control files > (``debian/control``) if needed in other situations. > > +.. _s-f-Build-Indep-Architecture: > + > +``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. > + > .. _s5.7: -- Sean Whitton
Re: Bug#846970: Patch to document Build-Indep-Architecture field
UNSUBSCRIBE On 06/14/2018 03:49 PM, Jess Hall wrote: On Sat, 14 Oct 2017 Sean Whitton wrote: On Sat, Oct 14 2017, Mattia Rizzolo wrote: On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: +maintainer's control. The specification should entail that the +architecture-independent packages are buildable on at least two +architectures. [...] Also, I dislike the sentence in itself, I believe it should be more straightforward in conveying its meaning of "pretty please at least two arch". It has to be that way for cases like this: Build-Indep-architecture: !amd64 That entails that it builds on at least two architectures, but on a common reading of 'specify', it does not specify two archs. How about "You should not specify that the packages are buildable on only one architecture."?
Bug#846970: Patch to document Build-Indep-Architecture field
On Sat, 14 Oct 2017 Sean Whitton wrote: > On Sat, Oct 14 2017, Mattia Rizzolo wrote: > > On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: > >> +maintainer's control. The specification should entail that the > >> +architecture-independent packages are buildable on at least two > >> +architectures. [...] > > Also, I dislike the sentence in itself, I believe it should be more > > straightforward in conveying its meaning of "pretty please at least > > two arch". > > It has to be that way for cases like this: > > Build-Indep-architecture: !amd64 > > That entails that it builds on at least two architectures, but on a > common reading of 'specify', it does not specify two archs. How about "You should not specify that the packages are buildable on only one architecture."? -- Jess Hall
Bug#846970: Patch to document Build-Indep-Architecture field
Hello, On Sat, Oct 14 2017, Mattia Rizzolo wrote: > On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: >> I am seeking seconds for the following patch. > > Thank you for working on this! Thank you for the review, though I don't believe I need to update my patch in light of your comments. See responses below. >> - I've included the ability to specify the architectures on which the >> package is known /not/ to build. This seems useful because in many >> cases the architectures that don't work is precisely what the >> maintainer knows, and wants to document in machine-readable form. I >> don't buy the argument that it creates any additional uncertainty > > Whilst you did this, I think the proper syntax is not clear by your > wording. For example, I take that > Build-Indep-Architecture: !amd64 means "this thing builds > everywhere except amd64". But then, how can I specify "it builds on > all 32-bit architectures except i386", for example? I copied the wording from the Architecture: field. Just as it is not possible to say that an architecture-dependent package is buildable on all 32-bit archs except i386 without listing all those archs, it is not possible to specify that architecture-independent packages are buildable on all 32-bit archs except i386 without listing all those archs. We want Architecture: and Build-Indep-Architecture: to use the same format. I don't think we should try to extend our format at this point because there are already various parsers of Architecture:. > See the following inline comments: > >> +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 also implies a single word. > > But… > >> +maintainer's control. The specification should entail that the >> +architecture-independent packages are buildable on at least two >> +architectures. > > this is not compatible with the above: both cases say that you have to > provide at most one word, but how can you provide at least two > architectures if you have only one word and can't use a wildcard? It says that you /should/ provide at least two architectures. This is not a /must/ requirement, so it should still be possible to use a unique single word. > And if you can provide multiple words, you need to specify a separator > (whitespace vs comma, I suppose). This is detailed in the architecture wildcard spec. > Also, I dislike the sentence in itself, I believe it should be more > straightforward in conveying its meaning of "pretty please at least > two arch". It has to be that way for cases like this: Build-Indep-architecture: !amd64 That entails that it builds on at least two architectures, but on a common reading of 'specify', it does not specify two archs. -- Sean Whitton signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote: > I am seeking seconds for the following patch. Thank you for working on this! > - I've included the ability to specify the architectures on which the > package is known /not/ to build. This seems useful because in many > cases the architectures that don't work is precisely what the > maintainer knows, and wants to document in machine-readable form. I > don't buy the argument that it creates any additional uncertainty Whilst you did this, I think the proper syntax is not clear by your wording. For example, I take that Build-Indep-Architecture: !amd64 means "this thing builds everywhere except amd64". But then, how can I specify "it builds on all 32-bit architectures except i386", for example? See the following inline comments: > +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 also implies a single word. But… > +maintainer's control. The specification should entail that the > +architecture-independent packages are buildable on at least two > +architectures. this is not compatible with the above: both cases say that you have to provide at most one word, but how can you provide at least two architectures if you have only one word and can't use a wildcard? And if you can provide multiple words, you need to specify a separator (whitespace vs comma, I suppose). Also, I dislike the sentence in itself, I believe it should be more straightforward in conveying its meaning of "pretty please at least two arch". -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
control: tag -1 +patch Hello, I am seeking seconds for the following patch. Comments: - I've made the two architecture requirement a 'should', because I agree that we might otherwise end up with "amd64" being the only value anyone uses for this field. But perhaps it should be a 'recommends' - I've included the ability to specify the architectures on which the package is known /not/ to build. This seems useful because in many cases the architectures that don't work is precisely what the maintainer knows, and wants to document in machine-readable form. I don't buy the argument that it creates any additional uncertainty - Let's stick with th ename Build-Indep-Architecture since it's already in use in the archive. diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 0ee6684..c54a341 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -121,6 +121,8 @@ package) are: - :ref:`Build-Depends et al ` +- :ref:`Build-Indep-Architecture ` + - :ref:`Standards-Version ` (recommended) - :ref:`Homepage ` @@ -1016,6 +1018,29 @@ This field is automatically added to Debian source control files field may also be used in source package control files (``debian/control``) if needed in other situations. +.. _s-f-Build-Indep-Architecture: + +``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. The specification should entail that the +architecture-independent packages are buildable on at least two +architectures. This provides flexibility to the administrators of +autobuilder infrastructure. + .. _s5.7: User-defined fields -- Sean Whitton signature.asc Description: PGP signature
