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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature