Hello! This time, I’d like to take a look at the evolution of package management in Linux and explore the next generation of package management technologies that have recently become practical.
Package management has always been one of the central topics in the Linux ecosystem. Over the years, various approaches have been developed to solve the problem of managing software installation, removal, and dependency resolution.
Rather than another how-to guide, this article is intended as a light read over a cup of coffee. Let’s take a brief look back at the history of package management before exploring some of the newer technologies that are shaping its future.
Before Package Management
Today, Linux software is distributed as packages, and installing an application is often as simple as running a single command with a package manager.
However, before package formats became commonplace, installing software meant building it from source code yourself and manually placing the resulting binaries and configuration files into the appropriate directories.
Even today, software that isn’t packaged still has to be installed this way, so this isn’t entirely a thing of the past. That said, such cases have become much less common. Nowadays, even when software is built from source, it’s often packaged first and then installed through the package manager.
From the Past to the Present
Building and installing software every time you wanted to use it was far from convenient. To improve the user experience, various package management systems were developed over the years.
Different Linux distributions adopted different philosophies regarding package management, and in many ways, this diversity is one of the reasons why so many distributions exist today.
Automating Source Builds
One idea was simple: if software must be built from source anyway, why not automate the entire process?
This philosophy led to package management systems such as Ports on FreeBSD and Portage on Gentoo Linux.
By compiling software directly from source during installation, users could optimize applications for their own hardware and specify build-time options. The trade-off, however, was significantly longer installation times due to compilation.
The Binary Distribution Approach — Debian and Red Hat
Another approach was to distribute precompiled binaries instead of source code.
While this meant users could no longer fine-tune build options, installation became much faster because the software only needed to be copied into the appropriate locations.
Initially, binary packages were little more than compressed archives containing the compiled files. Over time, package formats evolved to include dependency information so that package managers could resolve required libraries automatically.
Debian established the APT package management system for .deb packages. By automatically resolving dependencies, APT made it possible for users to install and remove applications with simple apt-get commands instead of manually invoking dpkg. At the time, this was a revolutionary improvement and became one of the key strengths behind Debian’s reputation for stability and reliability.
For RPM-based distributions, the rpm command was initially the standard way to install packages. Unlike today, package management tools capable of automatically downloading packages and resolving dependencies were not yet widespread. Users often had to locate and install dependency packages manually before installing the desired RPM package.
Some distributions adopted solutions such as apt-rpm, which brought Debian’s APT-style dependency management to RPM packages. Later, tools such as YUM, urpmi, and YaST emerged, providing automatic dependency resolution and forming the foundation of package management in many Red Hat–based distributions.
From my own perspective, Linux in Japan during the late 1990s and early 2000s was often synonymous with Red Hat–based distributions. (I suspect this was partly because Vine Linux offered excellent Japanese language support.)
Before I started using Linux myself, I simply assumed that Linux software was distributed in .rpm format. I still remember how surprised I was when I first encountered Debian and its .deb packages.
Even many printer manufacturers continued distributing Linux drivers in RPM format until Ubuntu became widely adopted, which was probably a reflection of the Linux landscape at the time.
The Weaknesses of Traditional Package Management
Traditional package management systems have their limitations.
Libraries shared by multiple applications generally need to use a single version. As a result, if you want to upgrade a library for one particular application, other applications that depend on the same library may also be affected. This often leads to a cascade of version changes throughout the system.
For this reason, modern Linux distributions carefully manage entire software stacks—including libraries and dependencies—to ensure that all packages work together correctly. While this provides stability, it also means that users cannot freely install whichever version of a package they prefer, at least not through the distribution’s package management system.
Another issue is that each distribution has its own package manager and command set. This may not bother Linux enthusiasts, but not everyone who uses a computer enjoys learning distribution-specific commands. For users who simply want their computer to work like any other consumer appliance, the differences between apt, yum, dnf, pacman, and other package managers can be confusing.
As Linux becomes more widespread, having a distribution-independent way to install applications becomes increasingly important.
The Birth of NixOS
This brings us to NixOS, a Linux distribution that introduced itself as a purely functional distribution.
Explaining NixOS in detail is beyond the scope of this article, but one of its defining features is that both system configuration and package management are non-destructive and rollback-capable. It also uses its own functional programming language, the Nix Expression Language, to describe system configuration.
At the heart of NixOS is the Nix Package Manager.
In simple terms, every package—and all of its dependencies—is stored inside a uniquely generated directory whose name is derived from a hash. Different versions of the same package are stored in different directories, allowing multiple versions to coexist without conflicting with one another. This design elegantly solves both dependency management and version conflicts.
Interestingly, the Nix Package Manager is also available on macOS, making it useful beyond Linux.
Nix also inspired another package manager: GNU Guix, which focuses on providing only free software. Like Nix, Guix is distribution-independent, meaning it can even be installed on distributions such as Arch Linux. (Although the Arch Wiki notes that this configuration is not officially supported.)
A New Generation of Package Management
In recent years, package managers inspired by ideas similar to those behind Nix and GNU Guix have become much more familiar to everyday Linux users.
Two of the most prominent examples are Snap, developed by Canonical (the company behind Ubuntu), and Flatpak, which originated as a project of freedesktop.org.
Another technology worth mentioning is AppImage. Although it isn’t technically a package manager, it offers users a similar experience by allowing applications to run without being traditionally installed.
Snap — Canonical’s Universal Package Technology
Snap is a package technology developed by Canonical, the company behind Ubuntu.
Canonical describes Snap packages as Universal Linux Packages. Their goal is to create self-contained application packages that work across different Linux distributions.
From both a technical and conceptual standpoint, Snap is quite similar to Flatpak, which we’ll discuss next. Applications run inside isolated sandbox environments, allowing them to operate independently of the underlying system.
Developers create Snap packages using Snapcraft and publish them to the Snap Store. Users can then install applications either with the snap install command or directly through the Snap Store website.
Because applications run inside a sandbox, all required libraries and supporting software are bundled within the package itself. This makes applications largely independent of the host system, but it also results in significantly larger package sizes.
Although Snap aims to be distribution-independent, support outside Ubuntu has historically been somewhat inconsistent. As a result, many users still associate Snap primarily with Ubuntu. This may improve over time as adoption continues to grow.
You can browse available Snap packages in the Snapcraft Store:
Flatpak — A Package Technology from freedesktop.org
Like Snap, Flatpak runs applications inside sandboxed environments, allowing them to work independently of the host system.
Its goal is also similar: providing an easy, distribution-independent way to install applications.
However, because Flatpak originated as a freedesktop.org project, it has traditionally focused more on desktop GUI applications. Unlike Snap, which also targets system software and services, Flatpak is primarily intended for end-user desktop applications.
Flatpak distributes application data using OSTree. This allows different versions of applications to be managed efficiently using OSTree’s versioning mechanisms.
Compared with Nix’s approach of storing each package version in a separate hashed directory, OSTree can reduce storage requirements by sharing unchanged data between versions.
Flatpak retrieves applications from repositories, with Flathub serving as the official application repository.
AppImage — A Different Approach: Running Applications Without Installation
Strictly speaking, AppImage is not a package manager. Instead, it is a format for distributing self-contained application images.
Traditionally, applications are installed into the operating system and rely on shared libraries and other software already present on the system. AppImage takes a different approach: applications are not installed into the system at all. Instead, they run independently as standalone executable images.
As a result, AppImage applications are independent of both the Linux distribution and the libraries installed on the host system. From the user’s perspective, this makes it possible to run the same application across a wide variety of Linux environments without worrying about compatibility.
In that sense, AppImage truly delivers on the idea of portable Linux applications.
As a side note, the project was originally known as PortableLinuxApps, which clearly reflects its original goal of making Linux applications portable.
The trade-off is that AppImage bundles the libraries and other runtime components required by the application. Consequently, AppImage files tend to be significantly larger than traditional installation packages.
What Does the Future Hold?
We’ve looked at several modern package technologies, along with AppImage, which represents a different way of distributing and running applications.
So what does this mean for the package managers we’ve relied on for years—apt, yum, pacman, dnf, and others? Will they eventually become obsolete?
Of course, no one can predict the future with certainty. Personally, I believe that traditional package management systems and these newer technologies will continue to coexist for the foreseeable future.
Since technologies such as Snap, Flatpak, and AppImage rely on isolation or virtualization, they generally avoid interfering with the existing package management system. This allows both approaches to complement one another rather than compete directly.
My expectation is that traditional package managers such as apt, yum, and dnf will continue to manage the core components of the operating system, while user-facing desktop applications—such as office suites, web browsers, and media players—will increasingly be distributed through Snap, Flatpak, AppImage, and similar cross-distribution technologies.
Conclusion
I hope you enjoyed this short coffee-break tour through the history and evolution of Linux package management.
If you’re a regular reader of this blog, you may not have found many surprises here. Still, I think discussing Linux distributions and their package management philosophies is one of the enjoyable aspects of being part of the Linux community.
