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

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