Re: Questions about Rust team for Kangrejos
On 9/15/25 12:22 PM, NoisyCoil wrote:
while I'm often tempted to introduce popular libraries in the archive
just for the sake of it, in the end I desist because in Rust Team
there's a high expectation that because of the fast-moving nature of the
Rust ecosystem users (specifically, developers) will not use Rust
libraries in the archive, and possibly not even the toolchain packaged
in Debian, to do any development work. If users don't need them, we're
not going to package them unless we do, which means libraries are
usually only introduced as (indirect, perhaps) dependencies of leaf
application packages.
Some more random side-notes I've observed over the past ~7 years -
What works best for us is a workflow of:
opensource/developers/upstream -> Debian -> users
There's a fluid concept of "latest opensource" that Debian tracks in
Debian unstable (as all other distros do as well) and then occasionally
freezes into stable releases.
Things get complicated when loops are introduced, e.g. somebody tries to
develop new software explicitly for Debian stable.
I recall one situation when an upstream intentionally depended on
outdated crates "because they build with Debian stable's Rust compiler".
The problem being we had trouble importing this crate into Debian
unstable because those outdated versions weren't available in Debian
unstable. We effectively had to "fork" the crate by heavily patching it
to build with the latest versions of it's dependencies we had in Debian.
That's somewhat backwards and I'd rather people create an LTS branch if
they want to cater to Debian stable users, without actually going
through Debian. :)
The barrier to entry is pleasantly low in the Debian Rust team and one
can contribute through merge requests in Debian's gitlab, it just takes
some patience and persistency to do the paperwork for all your dependencies.
---
Another note, there's multiple competing approaches to Rust in Debian,
but the one used by the debian-rust team is on a per-crate basis
(instead of per-workspace), meaning "split your library into many small
crates" makes things very difficult for us (the gix project is somewhat
notorious for this).
I was very happy when tokio decided to merge all their tokio-* crates
into just `tokio` for their 1.0.0 release (and I also advocated for this
in their issue tracker back then).
cheers,
kpcyrd
Reply to: