Debian’s APT package manager will have a “hard requirement” on Rust from May 2026. This move may make some rather big waves.

Debian and Ubuntu developer Julian Andres Klode emailed the debian-devel mailing list on Friday with a brief bombshell entitled Hard Rust requirements from May onward:

I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026. This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem.

In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.

If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.

It’s important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

In response to a message pointing out the unusually abrupt wording, Klode clarified:

Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv).

This explains two things. The smaller of them is that sqv is part of the Sequoia-PGP project, a Rust implementation of OpenPGP. The larger, though, is that Debian supports a lot more processor architectures – seven officially, and another 11 maintained ports – than Rust does. Rust’s official platform support lists three CPU architectures in Tier 1 (Arm64, i686 and x86-64). The other four architectures that Debian officially supports – armhf, ppc64el, riscv64 and s390x – are Tier 2 Rust platforms: they should be all right, but might need work.

That still leaves 11 unofficial-but-supported Debian platforms that aren’t high-class Rust citizens: the Debian ports for Alpha, HP PA-RISC, Hurd-i386 and Hurd-amd64, Loong64, M68k, PowerPC and PPC64, Sparc64, Sh4, and x32 (64-bit PC with 32-bit pointers). Rust has Tier 2 support for Loongson and SPARC64, so they may survive unscathed. Big-endian PowerPC is in Tier 3, which means it might be possible but with substantial work. It might be possible to save Debian on the GNU Hurd as it runs on supported processor architectures, just not operating system ones.

As Herr Klode notes, it looks like curtains for the other four: Debian on DEC Alpha, HP PA-RISC, Motorola 680x0, and Hitachi SH4. (Incidentally, if his name seems familiar, we have mentioned his work before, in connection with APT 3 and Keepass, as well as Ubuntu update troubles.)

We reported on Debian preparing to drop x86-32 way back in late 2023, and arguably, the writing has been on the wall since then. The Debian project’s strapline is “the universal operating system”, but that is coming to have some invisibly small print: “… for processors that are still being manufactured”. Debian is not an especially lightweight distribution, and retrocomputing is not a primary goal.

• A Linux alternative? Debian/Hurd shows microkernel Unix dream is alive
• Asmi Linux 13 Debian Edition debuts: Xfce desktop never looked so good
• Debian 13 ‘Trixie’ arrives: x86-32 and MIPS out, RISC-V in
• Debian isn’t waiting for 2038 to blow up, switches to 64-bit time for everything

A few months earlier, we had written about Debian’s 30th anniversary. The following year, we covered NetBSD’s 30th anniversary and the release of version 10. The NetBSD story was partly inspired by our attendance at a 2024 FOSDEM talk, NetBSD 10: Thirty years, still going strong!. The slide deck for that talk contained a sobering line on page eight:

Real talk:

There is no modern hardware that runs NetBSD but not Linux.

That’s still true, but the gap is starting to widen again. Debian still supports a number of 32-bit processor architectures, and running x86-32 binaries on x86-64 hardware, but we suspect that they may fade and drop away by Debian 15 or thereabouts. (That’s the release after next: Debian 14 is expected in 2027, so the following release would be about 2029.) We also suspect that the Linux kernel itself will drop official support for some older 32-bit x86 processors soon: it nearly happened in 6.15. Losing support for 32-bit as a whole will surely follow in time – perhaps when the project’s benevolent dictator deems it should be called kernel version 7.

That doesn’t mean it will instantly vanish. As a parallel example, the Epic Linux effort is still building current kernels for Intel’s long-discontinued Itanium IA64 processors, and we know of one distribution that still supports Itanic: the T2 System Development Environment, which forked from ROCK Linux in 2004. ®