bcachefs-tools

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinders Rust's adoption (as seen in this case). It's especially ridiculous considering Rust positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers for any non trivial project to not be malicious. https://github.com/koverstreet/bcachefs-tools/blob/b422b19f6...

> Packaging a dozen version of the same library? Cargo uses semver for unifying minor dependency versions, so you don't have dozens versions. It's one per major version. It's not even that different from what Debian does when they package "libfoo5" and "libfoo7". Cargo can have them coexist automatically without renaming, but apt needs this done manually, which creates lots of useless busywork for maintainers who need to map Cargo's requirements to apt's patched forks of Cargo packages. The real difference is that Cargo unifies versions by upgrading packages to the latest compatible version, and Debian unifies by downgrading to outdated incompatible unsupported junk. > What is the alternative to relaxing deps? In this case Debian has unforked bindgen, which removed an important patch that the project required: https://github.com/koverstre