Debian's Approach to Rust: Dependency Handling | Hacker News Reader

Debian's Approach to Rust: Dependency Handling

diziet.dreamwidth.org

25 pointsdsr_14 comments

Typical Debian:

"I am proposing that Debian should routinely compile Rust packages against dependencies in violation of the declared semver, and ship the results to Debian’s millions of users."

What could go possible wrong. We all know that debian maintainers have much better technical experience in managing complex dependencies, ha!

There is a similar problem with Go dependencies in Debian (and Fedora for that matter). I'm not entirely convinced it still makes sense to insist on splitting the dependencies and mixing their versions stunningly at random hoping that if the build succeeded the resulting artefact works lin a fashion that the upstream developer intended. If the problem is about reproducibility, the upstream is already free to specify their desired versions of libraries, so why not treat the whole package (with vemdored dependencies) as a single artifact and call it a day? It's not like those dependencies can be separately updated like shared libraries. Packaging node apps this way would be pure madness, it's only that neither Rust nor Go have reached the same level of dependency hell that discussions like this are even held.

Debian should simply not include Rust packages, except `rustup`.

These modern languages are designed to manage internally their own source-based software distribution. Inevitably, when combining with Debian's distribution system, the two redundant approaches step on one another's toes.

I do not want to compile packages from source. It is extremely wasteful. For Rust especially.

Me neither, but that's how Rust is designed. It's not for Debian to change that.

Sorry, I realized you're talking about build dependencies, not eg. individual programs that are written in Rust. I agree rustup should probably be the only Rust build dependency.

This is how python/node/ruby should be managed too.

It makes much more sense to have a thin layer on top that understands and interprets "install youtube-dl" or "upgrade youtube-dl" and delegates most of the work to pipx or something.

Ultimately it's not the maintainer's role to waste hours untangling the this mess. I do want ripgrep, but I see no value in forcing any particular version of ripgrep's dependencies on other rust programs that happen to use the same crate.

This doesn't work unless the entire dependency chain is Rust. Core libraries like librsvg and libimagequant that are used by a bunch of other things need to be provided by the distro. You're not going to point all of Gnome to "some user's home/.cargo/wherever shared libs go" so it can use graphics libs that have been rewritten in Rust.

Why require dependencies to exist in Debian to package a Rust build instead of just using Cargo?

It seems bonkers to try and solve this manufactured problem that Rust doesn't have to begin with

Probably because users aren’t that interested in using ‘just’ one more package management system.

But you kind of have to, unless your package manager has the same semantics as the other (which Debian does not)

Clearly the Debian developers think you don’t have to.

Fortunately, there are no programs in Rust that I need. Or that many people need.

In Haskell there is Pandoc. Some people use Git-annex. I haven't heard of any other Haskell programs.

I routinely delete all the Java and Mono runtimes. Nothing I use needs them. LibreOffice squeaks a bit, but settles down.

Reply on news.ycombinator.com