Re: Questions about Rust team for Kangrejos
On Mon, Sep 15, 2025, at 2:10 AM, Ben Hutchings wrote:
> Hello Debian Rustaceans,
>
> I'm giving a presentation for the Kangrejos conference this week about
> the status of Rust for Linux in Debian, and I need to provide some
> background about Debian's specific needs and practices. For the kernel
> and Debian in general I have this scovered, but I am still a Rust
> newbie.
Hi Ben,
Sorry for not getting back to you earlier, I know this answer is late for
(this year's) Kangrejos, but maybe it helps for a future presentation or
interested parties anyway.. Maybe I manage to attend next year as well!
> So I have a few questions about the Rust team's practices:
>
> - How do you choose which Rust toolchain version should go into a stable
> releaze? Is it simply the upstream version you are able to package
> before the toolchain freeze?
Mostly, yes. Because we effectively have/want to package each upstream
release one after the other, this is not always as easy as it sounds.
Since there is no "upstream LTS" release, and almost every release is
"equal" w.r.t. new features introduced, bugs fixes, etc, and the amount
of churn/development still happening in the wider ecosystem, targetting
the "most recent stable" version at the time of the freeze seems as good
a policy as any. Shaking out regressions is usually fairly quick (as
regressions are rather rare, and each version goes through experimental
and extensive testsuite triggering of both the toolchain and *a lot* of
crates, both upstream and in Debian).
For Bookworm, unstable was too far behind, so it was released with 1.63
(which was released upstream in August before the freeze).
For Bullseye it was similar - it released with 1.48, which was released
upstream in November before the freeze.
Those two were not that behind the latest upstream release nevertheless.
For Trixie, it was particularly important to include 1.85 (the first
upstream version with support for edition 2024, which was only released
as stable upstream on February 20th this year - such new editions are
one exception to the "each release is roughly equal" noted above). We
managed to do that thanks to an agreement with RT and uploading the RC
early on, so that the final stable release (which had a tiny delta
compared to the RC) could be unblocked for Trixie despite the toolchain
freeze.
> - I see that newer versions of rustc are backported as "rustc-web" and
> used to build browsers and a few other packages in (old)stable. Is
> there a policy for when to update this, beyond satisfying those
> applicationss' minimum versions?
No. Currently the respective maintainers prepare and handle those uploads,
depending on whether firefox-esr or chromium require a more recent rustc
(the same applies cbindgen-web).
For Trixie, I started (and plan on continuing to provide) backports of
each rustc version as soon as it hits testing.
Fabian
Reply to: