[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

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

> 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

Reply to: