As we know, I386 is dropped from Debian Ports starting with Trixie
i386 is not being dropped from Debian in trixie.
What *is* being dropped (has already been dropped) is the ability to
run i386 as a completely independent, bootable architecture, with its own
installer, bootloader and kernel.
From trixie onward, the scope of i386 is a partial architecture that
can be run as a chroot, a container or a multiarch foreign architecture
on an amd64 system. In particular, this is enough to run legacy 32-bit
binaries (native Linux executables directly, or Windows executables via
Wine), such as games.
At the moment it is also still possible to run i386 on 32-bit i686
hardware (Intel Pentium II, AMD Athlon XP or similar) **if** you upgrade
from an older version of Debian (install bookworm or older and then
upgrade, instead of installing as trixie), and either keep using the
old kernel, or build your own kernel. This will most likely not keep
working forever, but I would expect it to continue to be possible
(with enough determination) for the lifetime of trixie.
armel (32-bit ARM EABI softfloat) is in a similar situation, with the
architecture still existing as release-quality, but no installer, and
no kernel for most hardware.
Will i386 be moved to Debian Ports if support ends for it?
To the best of my understanding, i386 cannot be moved to Debian Ports
while it also exists in the main Debian archive; and it is not going
to be removed from the main Debian archive for the foreseeable future,
because we need at least a subset of it (notably glibc and Mesa) for
legacy 32-bit binaries.
Whether a separate port of Debian for older 32-bit x86 PCs will exist in
debian-ports is a question for the -ports maintainers who might be
interested in making it happen.
One possible situation that has been suggested is that we should have
two separate ports targeting 32-bit PCs:
- i386 is for legacy 32-bit binaries on amd64 systems, might have its
baseline (minimum CPU) either the same as it is now (i686) or raised
to match amd64, and continues to have 32-bit time_t forever, for
compatibility with legacy 32-bit binaries
- and there is a new port in -ports for users of 20+-year-old 32-bit x86
hardware, perhaps named i386t64 or ia32 or something, with a baseline
equal to or lower than the current i386 baseline, a 64-bit time_t for
futureproofing, and no compatibility with legacy binaries
But that will only happen if someone steps up to be responsible for the
new port existing and being maintained. Given that this new port would
be targeting hardware that is already rather old, there has not been
much enthusiasm for that: retrocomputing enthusiasts who are using this
hardware *because* it's old would perhaps be better served by using a
period-appropriate operating system like Debian 4, and anyone who just
wants a computer that works would probably find that they get better
power consumption and hardware compatibility from a second-hand modern
laptop that would otherwise have already become e-waste.
If this two-architecture situation does happen, the backwards-compatible
architecture for legacy 32-bit binaries needs to continue to be named
"i386", because that's what is already assumed by third-party binary-only
software that is not under our control.
smcv