I hate packaging my software for Linux

Original Article ↗ Hacker News Discussion ↗

Independent developers are struggling to distribute Linux applications across a fragmented ecosystem of distros, package managers, and runtime assumptions. Many argue it’s unrealistic for a solo maintainer to support every format and advocate instead for either shipping simple static binaries or leaving packaging to distro maintainers, even if that limits reach and auto-update convenience. Others explore workarounds like self-updating binaries, container-style approaches (Flatpak, Docker, Nix), or external tools, but there is no consensus on a universal, low-friction solution.

Scope of the Problem

  • Thread agrees Linux packaging is fragmented: many distros, many package managers, plus newer layers (Flatpak, Snap, AppImage, Nix, Homebrew, etc.).
  • Solo maintainers find it hard to cover all distros and keep updates flowing, especially for non-trivial dependencies (e.g., Rust with many crates, Python, etc.).

Who Should Package?

  • One camp: developer should mainly ship source, simple build instructions, and maybe a tarball or static binary; distro maintainers are expected to do distro-specific packaging.
  • Counterpoint: relying on distros means software can be effectively unavailable if no maintainer steps up; users may lack skills/time to package or build.
  • Some argue it has “worked for decades”; others note it filters out software and frustrates non-expert users.

Static & Self-Updating Binaries

  • Many see a single static (or mostly static) binary plus built‑in self-update as the most pragmatic cross‑distro solution, especially for CLIs/TUIs.
  • Examples cited: other Rust tools, Firefox’s own updater, various Go/Rust utilities.
  • Concerns: performance (musl vs glibc), security of self-modifying executables, and social pushback from some Linux circles.

Alternative Distribution Channels

  • Container-ish solutions: Docker/Podman/systemd-nspawn or shipping a whole userspace/squashfs seen as reliable but heavy, especially for embedded or low-storage systems.
  • Steam/Proton: suggested as a way to get long-term, stable runtimes for GUI apps, but UX is odd for non-games and depends on a proprietary platform.
  • Flatpak: works well for GUI apps, but CLI/TUI support and permission model are seen as awkward.
  • Nix, OBS, PPAs, personal Debian repos, Homebrew on Linux mentioned as useful, but each adds its own complexity and learning curve.

Build-from-Source & Tooling

  • Traditional ./configure && make && make install (or cargo install) is viewed by some as still viable; others say it often fails due to dependency mismatches.
  • Several comments suggest using modern tooling and CI (Nix, GitHub Actions, Open Build Service, checkinstall) and even LLMs to auto-generate packaging metadata.

Windows/macOS Comparisons

  • Multiple posters claim Windows packaging is easier in practice: bundle all DLLs with the app and ship installers.
  • macOS and mobile platforms have their own bureaucracy (certs, stores), but at least present a relatively unified path, unlike the Linux ecosystem.