Linux package managers

Why Linux has four+ ways to ship the same app — each format picked a
different problem to solve first.

The field

  • deb/rpm (native) — system components that must follow the
    distribution lifecycle: kernels, drivers, services. Deep host
    integration, but every distro/release needs its own recipe and testing.
    The baseline everything else reacts to.
  • Flatpak — cross-distro desktop apps. Versioned runtimes,
    Bubblewrap sandbox with static permissions + XDG portals, Flathub as the
    public catalogue. The mature default for GUI apps today.
  • Snap — desktop/server/device software in Canonical’s
    ecosystem: snapd daemon, AppArmor/seccomp strict confinement,
    interfaces, channels, automatic refreshes, Ubuntu-first integration.
  • cpak — the newest entrant (2023): OCI images as packages, Git
    repo as identity, decentralized distribution. Deep dive: cpak.

(Also in the space: AppImage — one portable executable, no sandbox, no
updates; Distrobox — mutable dev containers, not an app catalogue.)

Same axes, different trade-offs

native debFlatpakSnapcpak
Build inputdistro recipesflatpak manifestsnapcraft.yamlContainerfile + cpak.json
Shared basehost libsversioned runtimesbase snapsOCI layers, deduped
Isolationnone by defaultBubblewrap + portalsAppArmor + interfacesnamespaces + manifest permissions
Distributiondistro reposremotes / FlathubSnap Store onlyany Git origin + OCI registry
Update modeldistro cycleper-appdaemon auto-refreshgit-native (branch/tag/sha)
Scopesystemdesktopdesktop+server+devicedesktop, tools, services, sessions

The fault lines: who owns the update path (distro vs store vs
publisher’s git), how isolation is granted (portals vs interfaces vs
declared manifest permissions), and what the artifact is (tarball vs
runtime bundle vs OCI image).

Why it matters in practice

A Wine manager like Bottles ships on Flatpak but hit sandbox walls
with runners/dependencies — its cpak package exists precisely because the
Flatpak sandbox constrained the “download and execute arbitrary Windows
binaries” use case. Format choice is an architectural decision, not
packaging trivia.

Comparison source: cpak’s own format comparison
(vendor doc — mechanics accurate, judgment biased toward cpak).