On Sun, 16 Aug 2026 at 18:06:14 +0900, Charles Plessy wrote:
the scope of the i386 architecture is opt-out rather than
opt-in
Usually all architectures are opt-out rather than opt-in (even -ports) -
this is how Debian's portability has always been structured. The i386
buildds will attempt to build most packages on i386, unless told not to.
I'm not saying that this is necessarily the best way, but it's what is
true right now, and I think it's fair to say that we wouldn't have
anywhere near the architecture coverage we do on architectures like
arm64 and riscv64 if supporting those architectures was opt-in.
Some source packages use "Architecture: amd64 arm64 ..." instead of
"Architecture: any", and for *those* packages, i386 is opt-in. I think
this makes most sense for packages that are sufficiently low-level that
their design requires specific porting work for each new architecture,
like libffi, valgrind or libseccomp - when we add a new architecture,
for example loong64, those packages are expected to fail their build
until a loong64 porter adds an appropriate architecture-specific code
path, and there's no point in trying it until that code path has been
written, because we already know it's going to fail.
But most packages with higher-level code are portable-in-principle to
any architecture, and it's "just" a matter of whether
architecture-specific quirks like word size, endianness and
excess-precision break the package's assumptions.
And, yes, there's definitely a trade-off between fixing those bugs
(sometimes against upstream's objections, and sometimes requiring effort
that is out of all proportion to the package's usefulness), vs. treating
them as non-bugs because the package isn't actually practically useful
on all of our architectures.
We disable i386 building for this package
[creating] extra work for the maintainer
...
Unfortunately these workarounds do not solve the problem of needing
recursive removal of binary packages when removing architectures.
I think a large part of the problem here is that because excluding
packages from an architecture is something we've historically treated as
exceptional at best and a serious bug at worst, our process for doing so
requires asking others for permission, having to justify yourself, and
"expensive" manual intervention - to remove a non-leaf package from an
architecture where it's broken, you have to ask the archive team to
remove all of its reverse-dependencies first, and then the non-leaf
package itself, in one bug report per source package. I think Debian
could benefit from having a more scalable way to remove sets of
packages, particularly on an architecture-specific basis.
This gets worse (more teams involved) for packages that are involved in
d-i, as we've seen when removing the GNOME desktop environment from
armel after mozjs (and therefore gjs, and therefore GNOME Shell) started
requiring lock-free atomic operations that aren't available in the armel
baseline.
Also
Salsa CI does not stop testing i386 packages even if the source package
is designed to not build them.
This part, at least, could be solved by the Salsa-CI team making the
i386 build opt-in rather than opt-out - although I don't think that
necessarily makes sense until/unless it becomes easier to remove
packages and packaging ecosystems from i386 when they aren't needed
there or don't make sense there.
With team-specific architecture-restriction metapackages like
r-pkg-team-core-architecture, teams can focus their time on maintaining
a curated subset of Debian release architectures. However, we lose
valuable data indicating when or how a dropped architecture might become
viable again.
I think there's a distinction to be made between "we're removing package
P from architecture A because there's a practical problem, but it might
come back if the architecture A porters can help" vs. "we're
preemptively removing package P from architecture A because it's no
longer useful there, and it's unlikely to come back". i386 will often
fall into the second category.
smcv
