By joe brockmeier
24 November 2025
It’s rarely newsworthy when a project or package picks up a new dependency. However, changes to core tools like Debian’s Advanced Package Tool (APT) can have far-reaching effects. For example, Julien Andres Claude’s announcement that APT will require Rust in May 2026 means that some unofficial ports of Debian will either have to acquire a working Rust toolchain or rely on an older version of APT. This has raised many questions within the project, particularly regarding the ability of a single maintainer to make changes with wide impact.
On October 31, Claude sent an announcement to the debian-devel mailing list that they intended to introduce Rust dependencies and code into APT by May 2026 at the earliest:
This first extends to the Rust compiler and standard libraries and the Sequoia ecosystem.
In particular, our code for parsing .deb, .ar, .tar, and HTTP signature verification code would strongly benefit from memory safe languages and a robust approach to unit testing.
If you maintain a port without a Rust toolchain, please ensure it has one within the next 6 months, or shut down the port.
Claude said that this was necessary so that the project could move forward as a whole, relying on modern technologies, “And don’t shy away from trying to install modern software on retro computing devices
“. Some Debian developers welcomed the news. Paul Tagliamonte acknowledged that it would affect unofficial Debian ports but described it as a push towards Rust.”welcome news
,
However, John Paul Adrien Glaubitz complained that Claude’s words were obnoxious and the approach confrontational. In another message, he explained that he was not against adopting Rust; He worked on enabling Rust on multiple Debian architectures and helped fix architecture-specific bugs in the Rust toolchain as well as LLVM upstream. However, the message strongly suggested that there was no scope for change of plans: Claude ended his message with “thanks for understanding
“, which led to no further discussion. Glaubitz was one of the few Debian developers who expressed discomfort with Clod’s communication style in the message.
Claude summarized that Rust was already a hard requirement for all Debian release architectures and ports, except Alpha (alpha), Motorola 680×0 (m68k), PA-RISC (hppa), and SuperH (sh4), because the Sequoia-PGP project was used by APT. SQV Tool to verify OpenPGP signatures. APT is back to using the GNU Privacy Guard signature-verification tool, gpgvOn ports that don’t have a Rust compiler. However, by relying directly on Rust, APT will not be available on ports without the Rust compiler itself. LWN recently covered the state of Linux architecture support and the state of Rust support for each.
LWN.net is able to bring you articles like this because of its generous subscribers. If you want to see more of this, consider taking advantage of our special offer: 1 month trial subscription
None of the ports listed by clod are officially supported by Debian today, or targeted for support in Debian 14 (“Forky”). The sh4 port has never been officially supported, and no other ports are supported since Debian 6.0. The actual impact on ports lacking Rust is also less dramatic than before. Glaubitz assured Antoine Boucher that “The ultimatum given by Julian doesn’t actually exist
“, but phrasing it that way”get more attention in the news
“. Boucher’s escort is rust_codegen_gccA GCC advance-timing code generator for Rust. Nothing, Glaubitz said, prevents ports from using a non-Rust version of APT until Boucher and others manage to bootstrap Rust for those ports.
Security theatre?
David Kalniński, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Claude mentioned from APT entirely. It requires only two devices, apt-ftparchive
And apt-get remove templatesHe said, and the only “serious use
” Of
apt-ftparchive Claude’s employer, Canonical, for its Launchpad software-collaboration platform. If they were removed from the main APT code base, it would not matter whether they were written in Rust, Python, or some other language, because the tools are not directly required for any given port.
Kalniński also questioned the claim that Rust was necessary to achieve the robust approach to unit testing that Claude mentioned:
You can definitely do unit testing in C++, we do. The main problem is that someone has to write those tests. Like documents.
There are none (besides our pre-existing integration tests) for your new solver example. You don’t seriously claim that this is because of C++? If you don’t like GoogleTest, which is what we currently have, I might suggest Doctest (as I did in previous installments). Many other frameworks exist with similar or different styles.
Claude hasn’t responded to those comments yet, which is a bit unfortunate given the fact that introducing a tighter reliance on Rust has implications beyond their own work on APT. It may well be that he has good answers to the questions, but it could also give the impression that Claude is simply tending to Rust. He is involved in the Ubuntu work of moving from GNU coreutils to Rust-based utils. The reasons given for that action are, again, around modernization and improved security – but simply switching to Rust does not automatically guarantee security, and there are many other considerations.
For example, Adrian Bunk pointed out that there are many Debian teams, along with tooling, who would be impressed by writing some apts in Rust. The release notes for Debian 13 (“Trixie”) mention that Debian’s infrastructure “There are currently problems rebuilding types of packages that systematically use static linking.
“, such as those with code written in Go and Rust. Thus, “These packages will be covered by limited security support until the infrastructure to deal with them is improved
“. Limited security support means that updates to the Rust libraries are likely to be released only when Debian publishes a point release, which happens approximately every two months. The security team specifically stated that SQV Fully supported, but still have outstanding issues.
Due to static-linking problem, at any time SQVThe dependencies, currently over 40 Rust crates, have had to be rebuilt due to a security issue, SQV (At least potentially) also requires reconstruction. There are also difficulties in tracking CVEs for all of its dependencies and understanding that a security vulnerability in a Rust crate may require updating the Rust programs that depend on it.
Fabian Grünbichler, maintainer of Debian’s Rust toolchain, listed several outstanding problems Debian has had in dealing with Rust packages. One of the biggest needs is a consistent Debian policy for declaring statically linked libraries. In 2022, Guillem Jover added a control field for Debian packages called static-built-using (SBU), which will list the source packages used to build the binary. This will indicate that the binary package needs to be rebuilt due to an update to another source package. For example, SQV Relies on over 40 Rust crates packaged for Debian. Without declaring an SBU, it may not be clear whether SQV It needs to be updated when one of its dependencies is updated. Debian has been working on a policy requirement for SBUs since April 2024, but it has not been finalized or adopted yet.
From the discussion started by Grünbichler it is clear that most of Debian’s rust-related problems are in the process of being resolved. However, there is no evidence that Claude discovered the problems before announcing that APT would depend on Rust, or even asked “Is this a reasonable time frame to introduce the dependency?”
where tradition meets tomorrow
Debian’s tagline, or at least one of its taglines, is “universal operating system”, meaning that the project aims to run on a wide variety of hardware (old and new) and be usable on desktops, servers, IoT devices, and other devices. The “Why Debian” page lists several reasons why users and developers should choose the distribution: multiple hardware architectures, long-term support, and its democratic governance structure are some of the arguments it puts forward in favor of Debian. It also notes that “Debian cannot be controlled by any one company
“. A single developer, appointed by a company to work on Debian Tools, is pushing, without discussion or debate, a change that seems beneficial to that company, which impacts multiple hardware architectures and which requires other volunteers to do unplanned work or meet artificial deadlines, which goes against many of the project’s stated values.
Of course, Debian has checks and balances that can be employed if other Debian developers deem it necessary. For example, someone might appeal to Debian’s technical committee, or sponsor a general resolution to override a developer if they cannot be persuaded by discussion alone. This happened recently when the committee was required to provide system maintainers /var/lock Directory “Until satisfactory migration of the affected software is completed and the policy is updated accordingly
,
However, it also seems fair to point out that Debian can sometimes move slowly, even glacially. APT added support for the DEB822 format to its source information lists in 2015. Despite APT supporting that format for years, Claude faced resistance in 2021 when he pushed for Debian to move to the new format before the Debian 12 (“bookworm”) release in 2021, but was unsuccessful. With the move to APT 3.0 it is now the default for Trixie, although APT will continue to support the older format for years to come.
The fact is that, no matter what Cloud does with apt, more and more free software is being written (or rewritten) in Rust. It is to everyone’s benefit to make it easier to support that software when it is packaged for Debian. Perhaps the project needs some developers who will be aggressive in improving their support for Rust to move the project forward more quickly. However, what is really needed is for more developers to lend a hand to do the work needed to support Rust, both on Debian and elsewhere, such as gccrsIt doesn’t seem in keeping with Debian’s community focus for a single developer to announce dependencies only to have other volunteers struggle to support them,
<a href