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
