3 ms·
Debian effectively does this. It doesn't actually implement the crates.io API, but when building a Rust package they tell cargo "look in this directory for depe
by thristian 2y ago
Debian effectively does this. It doesn't actually implement the crates.io API, but when building a Rust package they tell cargo "look in this directory for dependencies, don't talk to the network".
As I understand it, the process goes something like this:
- Debian wants to package a Rust tool
- They examine the tool's Cargo.toml file to determine its immediate dependencies
- Those Rust dependencies are converted into Debian package names
- Generate a Debian package definition that lists those dependencies under "Build-Depends"
- When building the Debian package in an isolated environment, Build-Depends packages are installed, providing things like `rustc` and `cargo` as well as putting the dependencies' source into the "local dependencies" directory
- Cargo runs, configured to only look in the "local dependencies" directory for dependencies
- the resulting binary is scooped up and packaged
- actionfromafar 2y agoIs there some documentation on how to do this yourself? It sounds very useful for building software meant to be binary distributed.
- mkesper 2y agoThe whole process seems to be compiled in this Readme: https://salsa.debian.org/rust-team/debcargo-conf/blob/master/README.rst https://salsa.debian.org/rust-team/debcargo-conf/blob/master... How to use only local packages can be found in the last paragraph.
- nesarkvechnep 2y agoIs this documented anywhere?
- thristian 2y agoSee https://wiki.debian.org/Teams/RustPackaging/Policy https://wiki.debian.org/Teams/RustPackaging/Policy
- josephg 2y agoIs this automated? Does doing this manually do anything for Debian other than create a headache and a mountain of work? If it were up to me, I’d consider carving off part of the Debian package namespace - like cargo—* for cargo packages, and just auto-create them (recursively) based on the package name in cargo. There are a few things to figure out - like security, and manually patched packages, and integrating with cargo itself. But it seems like it should be possible to make something like this work with minimal human intervention.
- thristian 2y agoYes, it's heavily automated.
- IshKebab 2y agoWhy not just vendor the source for each Rust tool separately? A lot simpler and more reliable. The only downside I can see is disk space usage on the builder machines, but it's source code... is it really that big?
- steveklabnik 2y agoGenerally distributions want to unify dependencies so that if there’s a security fix, they only need to do it once instead of for every program.
- oconnor663 2y ago> Debian effectively does this. It doesn't actually implement the crates.io API, but when building a Rust package they tell cargo "look in this directory for dependencies, don't talk to the network". That sounds close to what I had in mind, but I assume you run into problems with the finer points of Rust's dependency model. Like if I depend on libfoo v1, and you depend on libfoo v2, there are a lot of situations (not all) where Cargo will happily link in both versions of libfoo, and applications that depend on both of us will Just Work. But if libfoo needs to be its own Debian package, does that mean every major version is a different package? That's the first question that comes to mind, but I'm sure there are others like it. (Optional features? Build vs test dependencies?) In short, dependency models (like Cargo's and Debian/APT's) are actually pretty complicated, and ideally you want to find a way to avoid forcing one to represent all the features of the other. Not that I have any great ideas though :p