APT Rust requirement raises questions

Original Article ↗ Hacker News Discussion ↗

Rust-to-C Transpilation Debate

  • Some argue a Rust→C transpiler would avoid needing Rust toolchains on all architectures. Others counter that:
    • Rust’s LLVM IR cannot be mapped cleanly to portable C because C has lots of undefined behavior (e.g., signed overflow, pointer aliasing) that Rust defines differently.
    • You’d either need to target a very narrow “gcc-with-specific-flags” dialect or generate verbose, non‑idiomatic C to preserve semantics.
    • Assembly is a simpler, more predictable target; C is a high-level language with complex semantics and aggressive compilers.
  • Existing projects (mrustc, GCC backends) are mentioned as partial alternatives but don’t remove the core portability and semantics issues.

Rust in APT & “Rewrite It in Rust”

  • One camp sees Rust in APT as sensible: APT is critical supply‑chain infrastructure with complex parsers and string handling; memory safety and stronger checks are desirable.
  • The opposing camp sees “Rust everywhere” as faddish, especially rewrites of “battle-tested” tools like sudo or coreutils, and worries about regressions, lost features, and license shifts (GPL→MIT).
  • Some distinguish between total rewrites and incremental refactors within existing codebases; the APT changes are framed by some as the latter.
  • Supporters say Rust attracts new contributors and reduces a large class of bugs, but skeptics stress it only prevents certain vulnerabilities and is not a panacea.

Debian Governance, Canonical, and Retro Ports

  • There’s strong criticism of the APT maintainer’s announcement tone (“retro computers”, “no room for change”) and the perception of a unilateral decision tied to Canonical’s needs.
  • Others counter that:
    • Debian must limit options to remain maintainable; many affected architectures (Alpha, m68k, hppa, sh4) are long‑unofficial and niche.
    • The maintainer did announce intent 1–2 years in advance on the proper list.
  • Some argue old ports still help expose subtle bugs and that dropping them, even if “unsupported”, weakens Debian’s “universal OS” ethos.
  • A commonly suggested compromise: move Rust‑using tools (e.g., archive parsers, Launchpad‑specific utilities) out of core APT so main package management remains buildable without Rust on exotic ports.

Security, Parsers, and Solvers

  • .deb/.ar/.tar parsing and signature handling are cited as risky areas; critics question the benefit of hardening .deb parsing if installing a malicious package is already “game over”.
  • Others reply that:
    • Metadata may be parsed before signature verification.
    • Defense in depth matters (e.g., PPAs, forges, provisioning environments).
  • The new Rust dependency solver is criticized for lacking a unit-test suite (though it has integration tests). Commenters note that solving dependencies is intrinsically hard and full of trade‑offs, regardless of language.

Rust Tooling, Dependencies, and Ecosystem Concerns

  • One side praises Cargo versus C/C++ (CMake, Autotools, pkg‑config), saying it makes adding dependencies trivial and portable.
  • Others see npm‑style, static‑linked dependency graphs as ill‑fitting for distros that rely on shared system libraries and easy mass rebuilds.
  • Some suggest waiting for mature GCC Rust support before hard‑depending on Rust for core distro components, to ease porting to new or marginal architectures.
  • A few express broader distrust of the Rust Foundation and fear Rust becoming a “Trojan horse” that later demands heavy corporate funding; others see this as speculative.

Evangelism, Tone, and Syntax

  • Multiple comments complain about aggressive “rewrite it in Rust” evangelism and language tribalism, arguing it alienates users and maintainers and causes reputational damage.
  • Others defend strong advocacy as a reaction to decades of C/C++ memory‑safety problems, but agree Rust rewrites should be judged by the same quality and stability standards.
  • A long tangent debates Rust syntax: some find it dense and “symbol‑heavy” (lifetimes, trait bounds, macros), especially compared to Python/Kotlin; others say it’s fine once familiar and that the real complexity comes from the semantics Rust must express (ownership, lifetimes, rich types), not mere punctuation.