Hi

I will like for ease of reading to define a new section 2.6 architecture

[proposal]

Debian uses a dual‑level architecture system in its packaging: arch:all
packages contain architecture‑independent content such as documentation, icons,
scripts, or pure Python or Java code, and are built once for all architectures.

This distinction allows Debian to efficiently manage multi‑architecture builds,
minimize duplication, and ensure that architecture‑specific optimizations or
constraints are respected during compilation and dependency resolution.

In contrast, arch:any packages contain compiled binaries and must be built
separately for each supported architecture (for instance amd64, arm64, riscv64,
s390x).

Each binary package produced from an arch:any source is tagged with its
specific architecture, while arch:all produces a single binary package shared
across the archive, for instance arch:amd64 or arch:S390x.

Archive wise package are compiled for a baseline that is a specific ABI and
ISA.

[rational]
- Ease of reading
- non normative only informal

[improvment]
- Next step will be to document generally multi arch and partial arch.
- document hwcaps

But one step as time.

rouca

https://www.debian.org/doc/debian-policy/ch-controlfields.html#multi-arch
has finally been documented...

(though I dont blame you for missing this, it was undocumented for >10 years.)

Le lundi 17 août 2026, 13:48:16 heure d’été d’Europe centrale Holger Levsen a écrit :

Yes I know but section 2.6 will be more a philosophical introduction to multi-arch something along

Multi‑Arch in Debian is the mechanism that allows a single system to install and use packages from multiple
architectures at the same time. It extends the architecture context so that libraries, headers, and binaries from foreign architectures (like i386 on an amd64 machine)
can coexist cleanly without file conflict. Individual packages declare their support for this feature, and influences the way dependencies are handled.
Moreinformation could be found in section 5.6.34

thanks holger for documenting.

[...]

ah, nice, this makes sense and is missing indeed. thank you!

Bastien Roucaries [17/Aug 12:16pm +02] wrote:

We wouldn't add a new section like this because it'd cause renumbering.
Instead we'd want to append a new section 2.13 to the chapter.

I'm not sure about adding a new section that contains only informative
text.  I think I'd like to see how this would be combined with some
text about relevant normative requirements that you think are currently
not documented.