Debian demands Rust or rust in peace for legacy ports 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 …
I’m not familiar with this and a little confused. Which bit of the system is going to have to be written in Rust? The package installers? If so then surely that’s “standard” (OS-wide) code anyway, no? And surely, it makes sense to use a single language for the installer (whatever that may be)
> So, as I understand it: This is something for distro builders and people self-compiling their debian OS. More specifically: people compiling the apt suite itself.
>
> Correct?
No.
It means that Debian ports for CPU architectures that can't run Rust code will no longer be possible.
Close, but no. apt isn't necessary to use dpkg. e.g. minimal and legacy architectures. Some of these might have a non-apt Debian system, but are either nearly abandoned or old enough a modern system may not be practical anyway.
TLDR this doesn't affect many people in reality.
This post has been deleted by its author
"Which bit of the system is going to have to be written in Rust?"
All of it that can be accessed through APT, near as I can tell ... Presumably this includes the kernel.
Looking forward to Debian sunsetting the Linux kernel on or about May 2026. Should be good for a giggle :-)
> I’m not familiar with this and a little confused.
I am sorry. Then I failed in my efforts due to my assumptions. But, seriously, no offence: if you don't know what this means then it doesn't apply to you and you need not worry at all.
If, for instance, you were running a *current* version of Debian on a DEC Alpha machine, then I think you'd know.
If you don't: relax. It will not affect you.
> Which bit of the system is going to have to be written in Rust?
*Parts* of APT. E.g. the bits that verify PGP signatures on packages.
APT is the tool that does package installation and updating on Debian. It does automatic dependency resolution. You basically need it to install software on Debian and to update Debian.
It will now need tools that don't work on some much-loved CPUs from the 1990s, and some moderately obscure RISC chips from expensive workstations from the late 1990s and early 2000s.
> The package installers?
Not really, no. Linux does not really have "installers" like Windows, anyway. The installer is part of the OS and third-party external ones are strongly discouraged (and would never work on the affected systems anyway).
> If so then surely that’s “standard” (OS-wide) code anyway, no?
Yes.
> And surely, it makes sense to use a single language for the installer (whatever that may be)
No. It's a patchwork of code in multiple languages. Essentially all of Linux is.
I’m not worried about it. I don’t run Debian and probably never will. I was just interested in what was going on. And I try and stay as far away as I can from Windows so any reference to that is probably lost on me, I’m afraid :-)
I think my misunderstanding stems from thinking “port” was an application port - such as a “port” of libre office. That’s what a “port” is in the BSD world. I wasn’t thinking that “port” was referring to moving the OS to a different platform. My fault for being dim.
It does seem, from the comments, I’m not the only one that was confused though
Seems fine to me -- this stuff takes work to support. Package manager bugs can be extremely annoying; I can't blame anyone for wanting to move away from messier implementations and bygone architectures.
As someone who likes Rust, though, this isn't fine... it's fantastic! `rustc` might make its way toward`build-essential`, and while I don't _love_ system-managed Rust installations, it's absolutely necessary for Debian to start using it more widely. These changes may empower more developers to start writing Rust, and more easily, too! :)
What dependency hell? Hasn't been a problem for quite a while. I've been using Debian (more recently Debian derived in the form of Devuan and Mint) since Debian 2.0(apt came out in 2.2). Only time I used testing was with debian 3, never used unstable though have built many packages from it over the years.
I did decide to abandon the desktop linux nextcloud file sync software in favor of syncthing recently due to suspecting newer versions will be more difficult to run on my Mint 22 system which I plan to run till 2030 or 2031. The dependency list on that app is absurd and I have no interest in running their container things. But that's just a side effect of trying to shoehorn newer stuff on older systems. Packages in the distribution repos should have no dependency issues.
I have managed to compile the gnome utility brightside which is critical to my daily workflow. It hasn't seen an upstream release since 2004, and last included in Ubuntu 16. Along with 17 other packages as dependencies I got it to built clean to last another 5 years.
I don't really have an opinion either way on the rust stuff at this point. Scrapping small ports doesn't seem too bad, not as if that hardware is getting maintenance anymore just run an older version of the distro or use netbsd or something. Windows 7 still runs fine today and even XP runs fine for retro gaming(on appropriate hardware for me that is a Toshiba tecra A11 laptop I bought in 2010), don't need the latest for everything.
If you want the latest, run more up to date hardware.
I like your thinking - C++ started out as a kind of pre-compiler that generated C code.
The problem here seems to be a lack of a rust implementation of OpenPGP on certain platforms, though, and a decision to just not support those platforms in lieu of making the library support them...
There is an implementation of OpenPGP on the other platforms: GnuPG. The decision includes having hard dependencies on Sequoia-PGP. The specific OpenPGP implementation isn't the only dependency though, going by the text quoted from Klode in the article, it suggests parts of APT will be implemented in Rust.
> Is there not a rust compiler with a K&R C backend?
I do not know what this means TBH.
The closest I can construct that seems related at all would be:
"Is there not a Rust compiler with a GCC backend?"
Yes there is.
https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Questions
... BUT it's experimental, not ready for production, and only compiles an older version of Rust.
So no, it will not help here.
There is only one rust compiler and there is no rust specification either - the language is a constantly moving target and the only program that can compile the compiler version N-1.
There is a C++ compiler (mrustc), but that can only compile rustc 1.74.0 at the newest, while the current rust verision is 1.91.0; https://blog.rust-lang.org/2025/10/30/Rust-1.91.0/
There is a lot of versions between 1.74.0 and 1.91.0; https://forge.rust-lang.org/infra/archive-stable-version-installers.html and bootstrapping rust takes and hundreds of gigabytes of storage.
There is gccrs, which will solve the bootstrapping problem, but after 7+ years of development, issue 49 on the github repository still cannot compile hello world (using github to develop gcc is unacceptable - but even such sinful drag on development doesn't slow down development that much) and even if gccrs ever manages to compile a release of rust, that still wouldn't solve the major functionality and security issue of your typical rust project relying on thousands of statically linked rust crates.
If a large development team was to spend 10 years writing a rust-to-C transpiler (it look >40 developers 10+ years to support rust 1.74.0; https://github.com/thepowersgang/mrustc/commits/master?after=da4075f17328474ba90d2b3b56dde6be1954eeea+5770), it'd stop working as soon as the next complexity increase is made to rust.
Regardless - unless there is an implementation of y language in x language (for example lua is implemented in C, which means embedding it in C programs doesn't cause issues), you shouldn't ever mix languages in projects - otherwise you'll always get a program that often ceases to compile and/or run and requires constant changes to make it compile and run again (something likened to cancer).
If a developer wants apt to have rust, that developer should write a pure-rust implementation of apt - but nobody would use that, as well it would break many things and lack much important functionality until after many years of development - thus the intention is to rust the current apt implementation.
(Just think about what happens to a building when its structural steel rusts through - that is exactly what rust intends to achieve - it's even admitted in the selected name).
I read the original debian mail thread before this, but I'm not well-versed enough in all of the various .deb tools and their dependencies to understand the full impact:
Does this pending Rust dependency affect all the .deb tools, or just the apt program itself? What about aptitude and dpkg? I'm assuming "yes" to all, since the announcement talks about APT (i.e. the package system) rather than 'apt' (i.e. the program). I'd likewise expect synaptic would be affected, as a front-end to apt.
I don't have much of a stake in this since I sadly don't have any of the potentially affected hardware, and if I did it would likely be running NetBSD anyway. ;-) But I'm wondering if there's a workaround of sorts available for folks, by using other .deb package tools.
... or is this hard requirement "upstream" from userland?
This kind of mandate is the sort of thing you'd expect from Microsoft because Windows is really only applicable to a narrow slice of application types. These may be really common and so widely used but it still boils down to just a single user working on a PC, interacting through a GUI and keyboard. (....with multimedia thrown in)
There's a place for memory safety but its a nonsense to think of it as a universal panacea.
I agree that a kernel is not comparable to an OS.
There are many languages that are memory safe.
Go is memory safe, python is memory safe, ada is memory safe, bash is memory safe, Java is memory safe and lisp is memory safe.
But interesting, the only language being pushed for memory safety despite the unstability and lack of a specification is rust.
Could it be that the reason is to eliminate the OS that must be completely eliminated to the point that it may not be named (using those before mentioned langues wouldn't do that, as that OS has compatible and portable implementations of those languages).
if we are talking desktop systems from late 1990s or very early 2000s even back then running Linux on the DEC and HP systems, from experience, was very slow - mostly memory constrained I suspect.
Realistically unless you have server hardware with plenty of ram, running a modern distribution is going to be unusable - the linux kernel ported to wasm is faster.
Probably firmly in retro·computing territory now.
I don't know how much of this hardware is still functional - sdf.org have [HP-UX hkypux B.10.20 A 9000/715 (ttyp1)]† but I don't know whether that is an emulator or hardware; likewise for their Alpha.
† ssh hkypux@bitzone.sdf.org icm/ICMguest
Memory safety is being used as an excuse to effectively dump old architechtures by lovers-of-the-new and promoters of the landfill ecocomy.
As pointed out in another post above, there are other, more-mature and better/more-widely-supported memory-safe languages. But there has been no campaign to convert to using them on the basis of memory safety.
Therefore, memory safety is not the true reason for this. Memory safety is being used as a "think of the children"-style emotional appeal.
Rust itself is like a talking dog: its promoters are so enamored of it being able to say, "Wow!" that they either don't notice, or willfully ignore its fleas.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
