we need to support each release of our product for a potentially long time.

we're targeting Debian stable, so we need to guarantee that crates like grpcio-sys or openssl will continue working for several years even with the old version of grpc and openssl that are available on Debian stable.

The people in charge of infra have a different perspective than mine. Therefore I'd like to move toward using a private registry, which could potentially mirror crates.io. Because we're human it's difficult to find the smallest set of dependencies that fits all our requirements and we end up with multiple versions of some crates in the project.

when backporting crates, we're manually doing the resolution work that cargo does for us automatically.

Some dependencies are simply unmaintained at this point it's difficult to get support from upstream for dependencies that are couple years old already.upstream patches we're interested in have to be manually backported.many tools like cargo-udeps, cargo-audit, cargo-tree are at least partially broken.

Internally we have infrastructure to create more debian packages for dependencies that are not available in the official repositories, but this is a tedious process. This means we're stuck with a fixed and outdated set of available crates. So far at work we've been using the debian infrastructure to manage our rust dependencies: our dependencies aren't pulled from a registry but from the local filesystem, where we install our crates as debian packages.

Debian package manager