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

Original Article ↗ Hacker News Discussion ↗

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.