Re: proposal [Forky i386] : linux-image-pentium4

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