The Debian Rust team has the pieces in place to start packaging Rust library crates and applications written in Rust. We have a packaging tool, debcargo, which automatically translates a Cargo crate into a Debian source package; we then have a Debhelper buildsystem, dh-cargo, which handles the package build.

We’ve drafted a preliminary packaging policy, and we’d love to get the Rust community’s feedback on it.

A few highlights:

Debian packages have to build using only other Debian packages, and must not access the network at build time. So, we need to package library crates for Rust applications to build-depend on. This works similar to vendoring, but on a distribution-wide scale.

Because Rust doesn’t have a stable shared-library ABI, and we don’t want to rebuild every Rust library package for every architecture every time we upload a new version of rustc, we package library crates as source code, installed into /usr/share/cargo/registry/cratename-version/ . Thus, the Debian “binary” package for a library crate contains the same source as the source package.

. Thus, the Debian “binary” package for a library crate contains the same source as the source package. We use a Cargo directory source to allow Cargo to build applications using the library crate sources.

We hope to use these tools and this policy to start packaging Rust applications for Debian (starting in experimental at first). High-priority Rust applications that we want to package include cargo itself (already packaged using vendoring within the source package, but this would greatly simplify it), debcargo, rustup, and ripgrep. We’d welcome any feedback on this approach.

cc: @lucab @alexcrichton