Orphaning bcachefs-tools in Debian

Original Article ↗ Hacker News Discussion ↗

Debian vs bcachefs‑tools: what happened

  • Debian’s Rust policy discourages heavy vendoring and expects crates to come from Debian’s own archive, built offline and reproducibly.
  • bcachefs‑tools pins exact Rust dependency versions, includes locally modified crates, and expects those versions to be used.
  • Debian maintainers tried to “unbundle” and replace vendored crates with distro versions (including an older bindgen), which broke builds and, more seriously, runtime behavior (mount options not passed; degraded mounts failing).
  • After technical friction and increasingly hostile interactions with upstream, the Debian maintainer orphaned the package.

Vendoring vs distribution policies

  • Distros argue: one version of each library and no vendoring keeps security manageable; they can patch a single copy and avoid chasing embedded forks (citing earlier zlib experience).
  • Vendoring advocates argue: for critical tools (filesystems, backups) exact, tested dependency sets are essential; distro‑level rewiring of deps reintroduces bugs and makes debugging and bisection harder.
  • Some suggest vendoring is fine for statically linked Rust/Go binaries; others respond that security teams still need to track and patch source, vendored or not.

Rust ecosystem and dependency churn

  • Several comments say the problem is ecosystem‑wide (Python, Ruby, ML stacks) but Rust’s culture of many small crates, weak standard library, and Cargo’s model amplifies it (dozens of transitive deps, multiple 0.x “major” versions).
  • Others note that in Rust it’s idiomatic to depend on semver ranges, not exact versions, but tooling for multiple major ranges is weak.
  • There’s debate on whether distributions misunderstand Rust versioning (e.g., treating 0.2 and 0.4 as “minor” instead of separate majors).

Stability, security, and release models

  • Debian is characterized as “waterfall” and long‑term‑support‑oriented, mismatched with fast‑moving software and immature ecosystems.
  • Supporters say that’s exactly Debian’s value: audited, reproducible, offline‑buildable, long‑lived systems where the distro—not every upstream—owns security backports.
  • Critics argue modern software stacks make that model increasingly untenable; suggest using distros as a stable base plus language/alt package managers (Nix, cargo, containers) for fast‑moving apps.

Perspectives on bcachefs and its maintainer

  • Some see a pattern of conflict with conservative processes (Debian, kernel release discipline) and describe upstream as overly aggressive.
  • Others emphasize the value of driven “move it forward” individuals for ambitious projects like new filesystems, while acknowledging social/process friction.