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

[Sean Whitton <spwhitton@spwhitton.name>]

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