Debian's Git Transition

Original Article ↗ Hacker News Discussion ↗

Motivation and Developer Experience

  • Several commenters say Debian’s current packaging workflow is painful, especially for newcomers; building a local package is described as “nothing but pain” unless you already know the tools.
  • The Git transition is seen by many as essential for Debian’s long‑term viability, with references to declining new contributors and burnout from existing tooling.
  • Some note this transition has been “in progress” for years, arguing Debian was “getting by” with patches and tarballs, but that “getting by” won’t last.

What the Git Transition Actually Changes

  • Most Debian work already uses git (via Salsa), but what’s in git today is often tarball‑based branches with quilted patches, not the true source state that produces the .debs.
  • The stated goal is that anyone who interacts with Debian source “should be able to do so entirely in git,” without being forced to understand Debian’s peculiar source package formats and quilt.
  • Tools like dgit and git‑buildpackage/gbp‑pq are discussed as bridges between patch stacks and git histories; the transition aims to make plain git commits the normal way to make changes.
  • Some worry it “just adds a new tool” during transition; others hope it will ultimately reduce the number of overlapping workflows.

Quilt, Patches, and Git Workflows

  • Quilt/“patch quilting” is widely criticized as archaic, footgun‑prone, and cognitively heavy compared to keeping patches as normal git commits and using git rebase.
  • Defenders point out quilt predates git and that Debian needed a tarball‑and‑patch workflow historically; gbp‑pq now gives a quilt‑compatible view on top of git.
  • There is debate over whether pure git (with rebase/merge) can fully replace a structured patch‑queue model, especially for tracking evolving downstream patches over time.

Tarballs, Provenance, and Reproducible Builds

  • A long subthread criticizes distro and language ecosystems that manually upload source tarballs or wheels instead of building directly from upstream commits.
  • Some argue package hosts (Debian, Fedora, PyPI, crates.io) should build artifacts from verifiable git commits and store source in a cryptographically traceable way.
  • Others respond that many projects’ “source tarballs” aren’t just repo snapshots, and that deterministic builds and provenance verification are non‑trivial.
  • For Debian, tag2upload is mentioned as an effort in this “build from git tags” direction.

Bug Tracker: Email vs Modern Web UIs

  • Debian’s email‑centric bug tracker is called archaic and clunky: following a bug requires email roundtrips, and there are no user accounts or simple “watch” buttons.
  • Pain points include spam exposure (email addresses made public), memorizing email commands, poor UX for casual users, and confusing status symbols.
  • Others defend the tracker as lightweight, functional, and free of JavaScript bloat, and wish for a dual interface: rich web UI plus the existing email workflow over the same data.

Patching Philosophy and Distro Comparisons

  • Many Debian packages carry patches because upstreams often don’t build cleanly in a distro environment or respect FHS/manpage policies; some claim “most” packages are patched.
  • Comparisons are made to distributions like Arch that try to minimize patches; historical Debian mistakes (e.g., infamous OpenSSL changes) are raised as cautionary tales.
  • A separate thread notes conflicts when distros heavily modify software (e.g., xscreensaver), fueling upstream frustration.

Source Co-location, Offline Builds, and Alternatives

  • Some dislike Debian’s model where source is embedded with packaging, preferring “ports‑style” systems that fetch source externally.
  • Debian’s rationale: every binary must be rebuildable from archived source, fully offline, for licensing and security reasons.
  • Others point out Gentoo/Nix‑style systems also sandbox builds but fetch sources at build time; critics say Nix in practice relies on opaque caches and link‑rotted URLs, illustrating pitfalls of that model.
  • A few large Debian packages already keep only debian/ in git and fetch upstream separately, raising questions about how that fits the new Git‑centric model.

Debian Culture and Pace of Change

  • Debian is characterized as slow to adapt, partly because it aims to package “the entire world,” making any systemic change massive.
  • Some former users report moving to faster‑moving distros (e.g., Arch derivatives) due to Debian’s pace and tooling, despite appreciation for Debian’s early FOSS leadership.
  • One commenter suggests using a visible “verification status” system (inspired by Steam Deck’s compatibility badges) to communicate transition progress and nudge maintainers.