On Fri, 14 Aug 2026 at 07:58:43 +0300, Martin-Éric Racine wrote:
ke 12.8.2026 klo 13.23 Martin-Éric Racine ([email protected]) kirjoitti:
shipping i386 as a demi-architecture simply doesn't make sense
It does make sense for exactly the use-case described in the release
notes: running legacy 32-bit binaries on an amd64 system.
Our friends in Ubuntu continue to put extra work into operating i386 as
a partial architecture (the only partial architecture they have, so
they've had to invent new mechanisms to achieve this). Why would they do
this, unless they believe an i386 partial architecture has significant
value?
Meanwhile our friends in non-Debian-derived distros (Red Hat, Arch,
etc.) historically had to invent a whole pre-multiarch mechanism to
support a subset of i386 packages (multilib), and they continue to put
extra work into its existence. Arch in particular has never supported
i386 hardware or kernels (it was x86_64 from the beginning), and yet
they still put effort into having "lib32-" packages for an i386 subset.
Again, I'm sure they'd be delighted to stop doing this work if they felt
that its cost exceeded its value, so we can take an implicit message
from the fact that they still do it.
It would be completely fine for the scope of i386 in Debian to continue
to decrease, as long as it still has the parts needed by legacy 32-bit
binaries (basically glibc, Mesa, Wine's dependencies[1], and their
recursive dependencies and build-deps). Ubuntu has been more aggressive
about removing the parts of i386 outside that set, but this is a
trade-off: our approach compiles a lot more code on i386 even in cases
where it's completely unnecessary, while their approach requires i386
special-cases in the build systems of more packages, and active
maintenance of a list of packages that are still required on i386. It
isn't yet obvious which one of these two approaches minimizes the work
required. If/when we reach a point where it becomes obvious which
approach results in less ongoing work being needed, I expect that both
Debian and Ubuntu will choose that one.
[1] Before someone says it, yes I know that recent versions of Wine
support "WoW64" mode, which can run 32-bit Windows/PE binaries using
only 64-bit Linux/ELF code. But it's also worth noting that the latest
release of Proton, a Wine derivative that many of Wine's upstream
developers work on full-time, is still running 32-bit programs by using
32-bit Linux/ELF dependencies and has not switched to WoW64 mode by
default. I think this is a good indication that WoW64 mode is not yet
considered to be the most reliable way to run legacy 32-bit Windows
programs.
introducing a linux-image-pentium4 would [...] come
with some performance and security benefits
I believe the kernel team's reason for dropping i386 kernels is that
they can't claim to provide the expected level of security for anything
i386, because any useful 32-bit x86 is new enough to have speculative
execution vulnerabilities, but the kernel only has mitigations for those
vulnerabilities on x86_64.
And, for the use-case stated in the release notes, a kernel is
unnecessary, because the machine can be assumed to be running an amd64
kernel.
If Debian will not at least do this much, then let's please do
everyone a favor and move i386 to debian-ports completely
I'm sure this has been mentioned in many similar threads in the past,
but to reiterate: for the use-case of running legacy 32-bit binaries on
an amd64 system, debian-ports would not be enough. debian-ports provides
an unstable derivative, but does not participate in transitions, does
not have the testing distribution, usually does not have binNMU'd
versions in sync with release architectures, and does not have stable
releases.
To be able to install i386 libraries via multiarch, we need the version
numbers of the i386 libraries to be in lockstep with their amd64
equivalents, otherwise they will not be installable ("multiarch skew").
This means that users of testing and stable need i386 to exist in
testing and stable, not just in unstable.
smcv
