Rust Is Coming To Debian's APT Package Manager (itsfoss.com) 70
A maintainer of Debian's Advanced Package Tool (APT) "has announced plans to introduce hard Rust dependencies into APT starting May 2026," reports the blog It's FOSS.
The integration targets critical areas like parsing .deb, .ar, and tar files plus HTTP signature verification using Sequoia. [APT maintainer Julian Andres Klode] said these components "would strongly benefit from memory safe languages and a stronger approach to unit testing."
He also gave a firm message to maintainers of Debian ports: "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."
The reasoning is straightforward. Debian wants to move forward with modern tools rather than being held back by legacy architecture... Debian ports running on CPU architectures without Rust compiler support have six months to add proper toolchains. If they can't meet this deadline, those ports will need to be discontinued. As a result, some obscure or legacy platforms may lose official support. For most users on mainstream architectures like x86_64 and ARM, nothing changes. Your APT will simply become more secure and reliable under the hood.
It's FOSS argues that "If done right, this could significantly strengthen APT's security and code quality."
And the blog Linuxiac also supports the move. "By embedding Rust into APT, the distro joins a growing number of major open-source projects, such as the Linux kernel, Firefox, and systemd, that are gradually adopting Rust. And if I had to guess, I'd say this is just one of the first steps toward even deeper Rust integration in this legendary distribution, which is a good thing."
He also gave a firm message to maintainers of Debian ports: "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."
The reasoning is straightforward. Debian wants to move forward with modern tools rather than being held back by legacy architecture... Debian ports running on CPU architectures without Rust compiler support have six months to add proper toolchains. If they can't meet this deadline, those ports will need to be discontinued. As a result, some obscure or legacy platforms may lose official support. For most users on mainstream architectures like x86_64 and ARM, nothing changes. Your APT will simply become more secure and reliable under the hood.
It's FOSS argues that "If done right, this could significantly strengthen APT's security and code quality."
And the blog Linuxiac also supports the move. "By embedding Rust into APT, the distro joins a growing number of major open-source projects, such as the Linux kernel, Firefox, and systemd, that are gradually adopting Rust. And if I had to guess, I'd say this is just one of the first steps toward even deeper Rust integration in this legendary distribution, which is a good thing."
Rustification (Score:5, Insightful)
The only thing Debian users are getting out of this is a man's self inflated ego and the loss of support for some architectures.
Re:Rustification (Score:4, Interesting)
Re: (Score:2)
Specific files related to input parsing:
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. -- https://lists.debian.org/debia... [debian.org]
Re: (Score:2)
The second part is clearly true, but the Ubuntu rust tools lacked working unit tests and didn't produce the behavior the real tools had. What about integration tests written in rust but not installed together with the tools? If there are better frameworks, you can use them to test the behavior of the tool without touching the tool itself.
Re:Rustification (Score:4, Interesting)
but the Ubuntu rust tools lacked working unit tests and didn't produce the behavior the real tools had.
The Debian maintainer specifically says he wants to write unit tests. How is it relevant that the Ubuntu team did not have any?
What about integration tests written in rust but not installed together with the tools?
That might solve the second part (the unit test), but not the first (parsing code benefits from memory-safe languages -- in that eliminates a class of vulnerabilities based on malformed input).
However, I think the maintainer should pledge to maintain apt-c together with the new apt-rust for the foreseeable future so that the uncommon architectures can still have a functional implementation. Mandating other architectures to have a rust toolchain or be dropped by Debian is very impolite.
Re: (Score:3)
Mandating other architectures to have a rust toolchain or be dropped by Debian is very impolite.
This should be emphasized. Douglas Crockford says, "breaking compatibility is an act of violence."
Re:Rustification (Score:5, Informative)
From his reply to a remark on the mailing list https://lists.debian.org/debian-devel/2025/10/msg00288.html [debian.org]:
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).
Looks like it's already a thing and thus inevitable. I just hope simple, straightforward software like openbox, remind, Xpad, won't break in the future.
Re:Rustification (Score:4, Interesting)
I don't understand your point. How would the inclusion of Rust in Debian break your favourite sticky note software? What could break them though, is if nobody ports them to Wayland. (Note: several Wayland compositors claim to have been inspired by Openbox https://www.gilesorr.com/wm/ta... [gilesorr.com] )
Re: (Score:2)
Clearly things are not being done correctly (ie, with established engineering practices). If he actually had an engineering license, it would be revoked because of decisions like this.
Re: (Score:2)
The engineering decision is made worse by the fact that making a fallback to support those platforms would be simple, and is already mostly implemented. It's a bad enough decision that I'd have to say the person who made it is not an engineer, he's just an asshole.
Re: (Score:1)
I think this is hyperbole. A fallback would be simple now, but would have to be maintained and tested.
At a certain point, you have to ask about the cost benefit from maintaining backward compatibility because it comes with a cost. Debian is not particularly designed as an light-weight, support architectures for every distribution.
The only reason, really, this makes news is because it is Rust which seems to trigger people for some reason.
Re: (Score:2)
Engineers think about user requirements.
Re: Rustification (Score:1)
And how many users are there of these architectures, who also want to be on the most recent Debian?
Re: (Score:2)
Re: (Score:2, Insightful)
How does this work on small embedded systems that lack the ability to even build rust? I don’t think a powerful enough RISC-V board exists to compile it natively. That now means RISC-V is dependent on amd64.
Re: Rustification (Score:4, Insightful)
What? There are plenty of arches supported by C that aren't supported by Rust. DEC, M68k, IA64, etc. are all targetable by gcc. None are fully supported by Rust.
Could they be? Sure. Are these targets niche? Sure. But Rust is nowhere near parity with C/C++.
GCC vs. LLVM (Score:3)
GCC has tended to support more historic instruction sets than LLVM. If a device's instruction set is supported by GCC and not by LLVM, it can run programs written in C, C++, Fortran, and other languages supported by GCC. It can also run programs in an interpreted language whose interpreter is implemented in a language supported by GCC, such as Python and PHP last I checked. It cannot build programs written in languages supported only by LLVM and not by GCC, such as latest stable Rust. What keeps gccrs (the
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
A complete rewrite in a new language is just as likely to introduce new bugs as updating the existing code.
Rust removes a whole class of bugs. So it's more likely to remove more bugs than it will introduce.
it's just in a language that some maintainer doesn't like
And? He's the maintainer, it can do whatever he wants. If you don't like it, feel free to fork. That's what open-source is all about.
But I guess forking would be too much work for you, so it's better to force _your_ preference onto the maintainer instead.
And talking about your preferences, are you an APT maintainer too? Or are you using one of those unsupported platform? If not, why would you care what languag
Re: (Score:2)
Or are you using one of those unsupported platform?
The most prolific poster on my Mastodon feed is a retrocomputing enthusiast who uses a decades-old (pre-Intel) Macintosh PowerBook G4 as their daily driver.
Re: (Score:1)
Rust removes a whole class of bugs. So it's more likely to remove more bugs than it will introduce.
Only if those bugs are of the memory kind. It will do nothing for the logical errors that meatbags tend to make when rewriting large codebases.
And? He's the maintainer, it can do whatever he wants. If you don't like it, feel free to fork.
And? Why should the maintainer get to demand what runs on other people's machines? Keep in mind his job is to maintain. He doesn't own the machines that code is running on, and those that do are the ones who will have to clean up the mess his new untested code makes.
Also, Re:Fork aka. the OSS way of saying "go fuck yourself", the entire point of a distribution is
Re: (Score:3)
"Rust removes a whole class of bugs. So it's more likely to remove more bugs than it will introduce."
Yes, Rust removes a whole class of bugs. But Ubuntu's recent screw up with their core utils in Rust indicates it's really easy to introduce other bugs in such a rewrite.
Mind you I expect Debian guys to be a lot more careful than the Ubuntu crowd.
We shall see...
Re: (Score:2)
Re: (Score:2)
Indeed. The first rule of software rewrites is simply: "Do not do it". Apparently some people are lacking in education on CS/IT history. Well, they may make it if the problem is small enough (not sure APT is), but they will rediscover things that are well known along the way. Let's hope they are not stupid enough to do away with the old APT before the new one works well (in 10 years or so).
Re: (Score:2)
You seem confused about how Debian's technical stewardship works. Technical directions are determined by involved developers, and only if consensus cannot be reached among developers then the Technical Committee may be called upon to resolve the dispute. There is no one man in charge of this process, your paranoid rant notwithstanding.
Re: (Score:2)
Well, apt is arguably a rewrite of apt-get, so why not rewrite it again, in memory safe?
Missing Rust Language Specification (Score:5, Interesting)
Re: (Score:2)
Apt is a package manager, adding one more language to it isn't a big deal. A lot of crap is there, moving in, moving out, whatever.
For an important API, yeah, it is probably a good idea if that API is something that you're told you can rely on, but I don't think this is still the case with the Linux kernel, where rust is more of a playground.
So your concern seems a bit premature.
Re: (Score:3)
Except there are real drivers being written in Rust. It's being done because it eliminates a class of memory bugs that were tricky and difficult in C, and when you're dealing with complex devices, likely an overhead you don't want to deal with (e.g., GPU drivers).
Sure, if you're a hard core kernel
Re: (Score:2)
Asahi Linux, for example relies on Rust on Linux code that's not in mainline yet - they're something like 600 patches that they have but cannot submit because the base dependencies are not in.
On the face of it, that sounds like the end result of poor decision-making by the Asahi developers.
Re: (Score:2)
Asahi Linux, for example relies on Rust on Linux code that's not in mainline yet
Well, cool. I read Asahi shimbun, I drink Asahi super dry, but I have no idea what is Asahi Linux. So I guess it will be a while before what it does becomes a concern for me.
Re: Missing Rust Language Specification (Score:2)
Bruh. Apt already relies on Perl, which has no formal language specification. What nonsense is this?
Re: (Score:2)
> Bruh. Apt already relies on Perl, which has no formal language specification. What nonsense is this?
You are right, which is why I don't think this is a huge deal.
Though perl5 compatibility back to c.2000 is pretty good.
Today's rust code most likely won't run in 2050 on modern compilers.
But perl4 code doesn't run well today either.
Yet nothing in trixie needs to run anything from buzz - so as long as everything works within a version or two it's hard to imagine anybody being negatively affected.
Re: (Score:2)
Do you expect perl to throw out backward compatibility? They won't, because they know exactly they will break 40 year old programs that are in daily use.
Re: Missing Rust Language Specification (Score:2)
Perl doesn't maintain backwards compatibility that far back. Perl 5 was released in 1994 and wasn't fully backwards compatible with Perl 4. Perl 6 was released in 2015 and was even less compatible with Perl 5.
Re: (Score:2)
Perl 6 was released in 2015 and was even less compatible with Perl 5.
They knew this and decided to maintain Perl 5 alongside Raku (formerly known as Perl 6) for what is looking to be noticeably longer than the 11-year transition from Python 2 to Python 3.
Re: (Score:2)
What, they still do not have a published full language spec? Why is anybody using this thing outside of experiments? It seems incompetence and lack of professionalism are now a Linux mainstream thing. Sad to see.
Re: (Score:2)
Lots of languages do not have a full spec. And even those that do, often have a spec which does not define all behaviour.
The main reason that people worried about a spec in the past was to avoid vendor lock-in. An implementation which is available under a public license is a good solution to that problem also. The full spec is well underway for those areas where it is a necessity, but it will track a few versions back.
Reflections on Rusting Trust (Score:2)
The main reason that people worried about a spec in the past was to avoid vendor lock-in. An implementation which is available under a public license is a good solution to that problem also.
Even apart from costs associated with proprietary software, the other reason to avoid vendor lock-in is to avoid self-propagating backdoors in the compiler. Ken Thompson described how to make such a backdoor with C in his 1983 "Reflections on Trusting Trust" speech. David A. Wheeler described "diverse double-compiling", a defense against compiler backdoors that relies on the existence of independent implementations of a language. Stable Rust doesn't have that because it's such a moving target, with widely u
Re: (Score:2)
Indeed. Sure, as an experimental language, Rust is fine. But a specifically "secure" programming language must be held to a higher standard. It seems the IT field is still bumbling around under the illusion they know what they are doing.
Re: (Score:3)
Sure. This one is specifically aimed at creating secure software. A full spec is _mandatory_ for that purpose or you cannot prove properties. Seriously. Some insight required.
Re: Missing Rust Language Specification (Score:2)
In so far as you can prove properties, you can do it with code as well as specification.
Re: (Score:2)
No. You cannot. This bullshit statement shows that you have no clue.
Re: (Score:2)
What do you mean? Plenty of languages are used to get a Linux system working, many without such a standard. Heck the kernel itself is not written in standard C, relying on GCC extensions as it does.
Rust Apocalypse (Score:2)
Wait for rust not being supported anymore. Rust is not C, it doesn't have dozens of implementations, it doesn't have millions of developers. Some day rust will stop being developed and you will have to choose from hundereds "rust-ng" forks that stop being supported in a matter of months and a few corporate forks following corporate interests. The migration back to C(++) tools will really hurt and be really expensive, when everyone now relies on rust rewrites.
Re: (Score:2)
"rust-ng"
"But how will we choose which Rust to use?"
"Simple. Kirk, Picard, Sisko, Janeway, Archer, Burnham, Pike, Rios, Shaw, or Seven?"
"I thought there were only two options...."
"Congrats you passed the first test, now answer the question."
Re: (Score:2)
Good point. Rust also hat the problem that it is really hard to learn and requires a lot of skill and experience to do so. Which makes the risk of Rust prematurely dying a lot more real.
On the other hand, while I am not convinced that Rust really makes code more secure (the incompetent will just make harder to find mistakes, but attackers can now use AI to help with that), that it is hard to learn may have that effect. The most serious problem we have in the software space is tons of incompetent and semi-co
Re: (Score:2)
The point about how hard it is to learn a language is interesting.
You for example find a lot JavaScript tools now, not only the thousands electron app but also command line tools, which all seem to have rather bad code quality, not just because of JavaScript but also because of careless coding. JavaScript is currently a popular beginner language, allows rapid development, but doesn't try to force people into doings things correctly like for example python attempts.
C on the other hand may lead even an interm
Re: (Score:2)
That is possible and it is always a risk with a new language. Then again, it is also a risk with old languages. Fewer people work on them, fewer know how to fix them, they just hang around and slowly wither away.
You should never rewrite code. You should never rely to legacy code. Get used to it, it's engineering, everything is a compromise.
Re: (Score:2)
That's true and one could argue for a few things that perl is also bad. How many implementations of perl are there? How much things does the language contain, that nobody would do this way anymore? But it exists for long enough, that even an implementation in maintenance mode would still work for a long time, and its modules are easy to package in distributions, making supply chain issues less complicated for components that work since decades.
Newer languages also tend to have too many recursive dependencie
So, this decision won't affect apt-get? (Score:1)
Re: (Score:1)
Re: (Score:2)
Discontinued ... (Score:2)
those ports will need to be discontinued
Alas, poor Debian. I knew him ...
Rust is not just memory safety (Score:2)
Rust has a complex and powerful algebraic type system. If used wisely, it can make invalid states impossible to express in the language. Part of the power is the capacity to use the language to make various classes of bugs hard, if not impossible to write. It's not a perfect fit for everything, but I think the 'Rust experiment' is going to happen and we'll see if memory safety and algebraic types are an overall improvement.
Re: (Score:2)
It does happen, but I am not sure this is what free software needs. We live in a world we adding a warning to a C compiler is carefully consider because it might overload maintainers. And lack of maintainers is the problem. The least thing we need is a more complex language that also has supply chain issues.
Re: (Score:2)
As long as it is clearly understood that this is an experiment, that is fine. Fully committing only to find out that Rust does not cut it would be a bad mistake. There are several serious problems with Rust, one being the lack of spec, another being that it is hard to learn (hence fewer maintainers). And "used wisely" requires that wisdom to be present and in use.
I will be watching this and it will be interesting to see how it will turn out. Just keep "There is no silver bullet" in mind.
Re: (Score:2)
Bad enough when they required python (Score:3)
Debian used to just require old school Unix stuff plus Perl, which is pretty old school really.
Then they started requiring Python for some tools.
They just keep adding more requirements which bloat the base install. This is the opposite of the right direction.
Re: (Score:2)
They just keep adding more requirements which bloat the base install. This is the opposite of the right direction.
Indeed. KISS is the basis of all solid engineering and complexity is the death of it. I do not think the people at the wheel are aware of that. Probably a lack of experience and insight, which would be bad on a whole other level.
Re: (Score:2)
Re: (Score:2)
I get the impression that they will require Rust for systems that compile Debian, not for all Debian systems.
Isn't this story about making apt depend on rust? apt is part of all Debian systems and derivatives.
Re: (Score:2)
Isn't this story about making apt depend on rust? apt is part of all Debian systems and derivatives.
apt sources will need Rust to compile. That doesn't mean that apt binaries will need Rust packages to run.
I suppose they could if they were linked dynamically to Rust libraries, but I think Rust by default links Rust libraries statically.
This is not progress (Score:1)