Package: debian-policy
Severity: normal
Following a recent discussion on debian-devel[0], I'd like to
formalize the (XS-)Build-Indep-Architecture: header mentioned there.
As an initial wording (probably 5.6.30):
This header is useful in the rare case where Architecture: all
packages cannot be built on all architectures for reasons outside the
maintainer's control. The value is an architecture wildcard
identifying a set of Debian machine architectures, see [Architecture
wildcards, Section 11.1.1], and should describe at least two
architectures. The default is "any".
Some thoughts:
The main reason for such a header is to give downstream/derivates/
backporters a machine-readable hint which archs are known to build the
arch:all packages. Perhaps also, which archs do not, see below. The
entire idea is somewhat band-aid since it works around an underlying
problem that should not exist but sometimes does. So usage of this
header should be seen as a last resort where such problems cannot be
fixed easily.
This header always puts a constraint on the downstream etc. folks, so
it's the maintainer's duty to alleviate this: By identifying more than
just one successful architecture. The "at least two archs" also serves
a purpose that might not be everyone's agenda: Avoid Debian
technically shrinks to linux-amd64, with perhaps a little linux-armhf.
Things that require more discussion:
# The name of the header
The alternative "Arch-Indep-Build-Arch" was used in LP#217427[1], and
I think I read about an third proposal in a Debian bugreport I'm
afraid cannot find anymore.
# Allowing negations
It might be an idea to allow negations as seen in the various Depends:
headers, e.g. "amd64 !i386" means "Was successful on amd64, known to
fail on i386, cannot tell about the rest".
Pros:
* The maintainer can document both successful and failing architectures.
* Thus downstream folks have a better hint which archs to avoid.
Cons:
* This creates more complexity in the description and the parser
* This creates also uncertaincy about the arch not mentioned
Cheers,
Christoph
[0] https://lists.debian.org/debian-devel/2016/11/msg00459.html
https://lists.debian.org/debian-devel/2016/11/msg00457.html
[1] https://bugs.launchpad.net/launchpad/+bug/217427
Attachment:
signature.asc
Description: Digital signature