MergeTB Debian packaging

DevOps
1

This discussion topic is about how we chose to name and version our Debian packages and lay out the repo.

The work that was done was I investigated whether our .deb’s actually diverge per Debian version. Added an md5sum diagnostic to the build (hashes staged files + the final .deb in the
job logs), built the same tag on deb12 and deb13, compared, and ran cross-distro
install tests against the live repo.

What we found

  • The binary is byte-identical across Debian versions (ymk md5 matched on deb12 vs deb13). This was expected as it’s a static Go binary, dependency chain resolved at build time, zero runtime deps.
  • The only differences between the two .deb’s were the +debNN version string and the dch build timestamp, i.e. no real per-OS divergence in contents.
  • +debNN only changes the filename, so identical bytes get stored twice in the pool (two inodes) instead of deduping to one.
  • For full reproducibility: Pinning the changelog date to the tag commit time makes the whole .deb byte-identical across builds.
  • Installs and runs cleanly on Debian 11/12/13 and Ubuntu 20.04/22.04/24.04 from a single suite, zero dependency closure on every target.

So for our decision, we name packages with bare versions and publish one shared .deb per package, served by a single suite (mergetb) from the shared pool. Codename suites are
reserved only for a package proven to diverge per-OS.

  • Version scheme: plain tag vX.Y.Z → X.Y.Z; point release vX.Y.Z-N →
    X.Y.Z-N.
  • Alternative considered: a per-OS +debNN suffix, i.e. per-suite rebuilds
    tagged +debNNuM (Debian’s default-for-safety convention). We passed on it as
    our static Go binaries are demonstrably identical across Debian versions, so
    the suffix would only duplicate pool storage with no correctness gain. It comes
    back only if a package is shown to actually diverge.

Template location & usage:

Canonical: mergetb/devops/pkg/debian/deb_build.bash (other repos, e.g.
ymk, vendor a copy).

Copy the debian/ directory into your project and run from the project root:

./debian/deb_build.bash
  • Locally: run as root or in CI (installs build-deps). No tag → builds the
    version already in debian/changelog.
  • In CI: stamps the version from $CI_COMMIT_TAG, derives SOURCE_DATE_EPOCH
    from $CI_COMMIT_TIMESTAMP, and pins the changelog date for a reproducible
    build. Requires GNU date/sed.