Why does Debian change software?

Original Article ↗ Hacker News Discussion ↗

Title and focus of the discussion

  • Several readers initially misread the article title as about package version churn or removals, not source-level modifications.
  • Some suggest “modify” or “patch” would better convey that Debian is changing upstream source code.

Why Debian patches software

  • Common reasons cited: backporting security fixes, making old code build with current toolchains, portability to non‑amd64 architectures, replacing removed language stdlib modules (e.g. Python), and cherry‑picking unreleased bug fixes.
  • Others mention Debian-specific integration changes (system paths, config defaults, multi‑instance setups) and adding missing man pages.

Privacy, ‘calling home’, and telemetry

  • Many praise Debian’s culture of stripping auto‑updates and phone‑home behavior, even if it’s not yet formal Policy; Firefox telemetry is given as an example that’s disabled in Debian builds.
  • Others stress this is best‑effort, not guaranteed; links are shared to Debian’s own privacy-issues page and tools like opensnitch/privoxy as extra defenses.
  • Debate over whether any telemetry can ever be non‑personal: some argue opt‑in + minimal data is fine; others note IPs and “anonymous” identifiers are often treated as personal data in practice.
  • Example complaints: visidata sending usage pings by default, GNOME contacting remote services, Discord and Spotify trying to self‑update even when packaged.

Security and the OpenSSL entropy bug

  • The infamous 2008 Debian‑specific OpenSSL RNG bug is raised as a counterpoint: distro patches can introduce catastrophic vulnerabilities.
  • Responses argue:
    • This was an extreme, one‑off failure; OpenSSL itself also had serious bugs.
    • The patch had been shown to OpenSSL (albeit on the wrong list) and lightly “approved”.
    • There is no dedicated penetration‑testing team for Debian patches, which matches most software ecosystems.

Upstream vs. distro responsibilities

  • Some upstream developers recount Debian patches that “fixed” spec compliance but broke real‑world behavior (e.g. RSS parsing library), causing hard‑to‑diagnose bugs and user reports that didn’t match upstream code.
  • Complaints that Debian doesn’t always notify upstream or clearly signal to users that they’re running a modified fork.
  • Debian packagers reply that:
    • All patches are publicly visible (source packages, patch trackers, quilt), and are usually sent upstream, but this is time‑consuming volunteer work, often ignored or delayed by upstream.
    • Patching is sometimes necessary for security, buildability, or integration; users explicitly choose that trade‑off by choosing Debian.

Man pages and documentation

  • Debian’s practice of writing man pages where upstream lacks them is lauded but also criticized: such docs can diverge from later upstream docs, stay buried in distro VCS, or become stale/wrong.
  • Some argue this reflects an old model where man pages are central; others note modern projects prefer --help/README/online docs.

Distro philosophies and alternatives

  • Some prefer Debian’s “integrated OS with opinionated defaults” and privacy stance; others migrate to Arch, NixOS, RHEL, Slackware, Devuan, etc. for:
    • Fewer functional patches and closer adherence to upstream behavior.
    • Different views on security hardening vs. rolling/bleeding‑edge.
  • There is disagreement over how heavily Debian actually patches compared to other major distros; claims both that “everyone patches” and that Debian goes further than most.