Remember universal package systems? Although AppImage [1], the earliest universal package system, was first released in 2004, the concept did not capture much attention until a decade later, when Canonical released Snappy [2] and Red Hat released Flatpak [3]. Each was presented as the next generation of package managers, usable by any distribution, and as a means to reduce the number of rival technologies. Yet in 2020, both Snappy and Flatpak have receded into the background, and the deb and RPM package management systems continue to dominate Linux, leaving the question of why Snappy and Flatpak did not fulfill their promises.

Two quick searches on DistroWatch reveal that, out of the 273 active distros listed, 39 support Flatpak [4], and 35 support Snap packages [5]. At first, those may sound like respectable numbers, until you realize that a much more arcane deviation from the norm, like distros that do not ship systemd, can boast 99 distros. Moreover, those figures consist mainly of major distros that support Flatpak and Snap – often both – but still depend primarily on traditional package managers.

Theory vs. Practice

A serious drawback to universal packages is that, to be truly universal, they require that each distribution be structured the same as others. Despite efforts like the Linux Standard Base, this requirement is simply not met. Many distros continue to place key files in different positions. For this reason, the promise that universal packages would reduce the amount of work needed to ship packages has no practical chance of being realized.

[...]