Currently I am trying to support cargo based packages on two source based distros. I will caveat this issue saying that my approach might be wrong but its a use case that I need a solution for. I've run into two main issues:

• reproducible builds - cargo currently might use a newer dependency at a later point for a package
• limited networking - cargo reaches out to the internet when networking might not be available

For source based distros they separate out building of packages into different stages. Roughly they are separated into:

• fetch
• unpack
• build
• install

The unpack, build, and install phases are run without networking available. This means that the traditional cargo model of download a crate and then pull down the dependencies and build them does not work. The issue is that the source for the crate has not yet been unpacked before I need to fetch down the remaining dependencies.

To work around this I have implemented native fetchers for Yocto and Gentoo similar to how npm packages are handled in those distros. I considered npm to be analogous to cargo but for JavaScript in this case. The fetchers grab a package, its dependencies and a copy of the cargo registry index at a specific point in time and create a $CARGO_HOME that matches the layout that cargo expects. Unfortunately this on disk format changes from time to time which makes this method fragile.

In an effort to make packaging of these crates easier I've started https://github.com/cardoe/cargo-bitbake and https://github.com/cardoe/cargo-ebuild which aims to eventually produce recipes for Yocto and Gentoo respectively that do everything necessary to package a crate for those distros.

For an example of distro recipes see:

• https://github.com/cardoe/gentoo/blob/ca3e8fcfc273a9320ee3c6f8abec95d16ff4dadb/dev-util/rustfmt/rustfmt-0.5.0.ebuild
• https://github.com/starlab-io/meta-rust/blob/9bc90a04094a4b50b346b83acecb3df912cd9824/recipes-example/rustfmt/rustfmt_0.4.0.bb