Debian's approach to Rust – Dependency handling (2022)

Original Article ↗ Hacker News Discussion ↗

Debian’s plan to compile Rust packages against shared system libraries, even when this violates the crates’ declared semantic version constraints, exposes a deep clash between traditional Linux distribution practices and modern language ecosystems. Critics warn that overriding Cargo’s dependency choices risks subtle stability and security bugs, shifts support burdens onto upstream developers, and undermines Rust’s expectation of reproducible, hermetic builds. Supporters of the distro model argue that a global set of shared libraries is still essential for efficient updates, security patching, and resource usage, but many see this approach as increasingly ill‑suited to Rust, Python, Go, and similar toolchains.

Debian’s proposed Rust policy

  • Debian is considering routinely compiling Rust packages against dependency versions that violate upstream semver constraints, then shipping those binaries.
  • Rationale: preserve Debian’s “global” dependency view, minimize duplicated libraries, ease system-wide security patching, and fit Rust into the traditional shared-library distro model.
  • Several commenters note it is unclear whether this proposal was ever fully adopted in practice.

Stability and security concerns

  • Many argue this will introduce subtle logic and stability bugs that upstream cannot reproduce or support.
  • Semantic changes often aren’t reflected in types (e.g., “take a string, return a string” APIs changing behavior), so type safety doesn’t prevent regressions.
  • Ignoring version constraints can undermine security too, e.g., by reintroducing versions with known vulnerabilities.
  • Some see this as “injecting bugs and waiting for users to report them,” which could be exploited by malicious actors.

Dynamic vs static linking and resource trade-offs

  • Distro maintainers emphasize benefits of shared libraries: lower disk/RAM use, faster updates (patch one library, fix many apps), and manageable SBOMs.
  • Others counter that modern systems can afford duplication and that static or bundled builds (as with Rust, Go, Python tools, containers, Flatpak/Snap) often “just work” better.
  • There’s disagreement on how big the resource cost is and whether it justifies Debian’s global versioning stance.

Distro model vs modern language ecosystems

  • Traditional distros assume one or a few versions of each library, dynamically linked, with the distro responsible for backports and CVE fixes.
  • Modern ecosystems (Rust/Cargo, Python/venv, Node/npm, Go) assume per-project dependency resolution, multiple versions, and often static linkage.
  • Some argue distros must adapt (vendored deps, app-level isolation, per-app envs); others insist the distro model is critical for security and maintainability.
  • Nix/Guix and containers are cited as alternative models; opinions differ on whether they solve or just relocate the problem.

Upstream–distro relationship and UX

  • Upstreams fear getting bug reports caused by distro-specific dependency changes they never tested.
  • Traditional expectation: users report to the distro first; in practice, many go straight to upstream (e.g., via GitHub), increasing upstream support burden.
  • Some developers say they would avoid or block such distro packaging; others accept distro autonomy but insist that any consequences are on the distro.