With Ubuntu releasing Snappy and Red Hat releasing Flatpak, suddenly universal package managers are in the news. Maybe we should talk about Guix too.

Both Snappy and Flatpak have their points of interest, but exaggerated claims about both of them are all too common. In this situation, GNU Guix, which for two years has been offering packages that run on any distribution, provides a much needed reality check — to say nothing of a practical and proven alternative.

According to developer Ricardo Wurmus, a solution like Guix is necessary because of the proliferation of package managers.

It seems that there are new per-language package managers appearing every month. All of them only handle a subset of a package’s dependencies. Installing a Ruby module with bindings to a system library? Only the Ruby part is handled by the package manager. The user needs to use other means to get the compiler toolchain, the needed libraries, and the headers.

At the same time, Wurmus continues, other package managers like Conda run into difficulties because their packages are not built in an isolated environment and make undeclared assumptions about the runtime environment that prevent them from running on other distributions or releases. According to Wurmus…

The current solution to this mess is to give up on packaging and the description of dependencies and shrink-wrap the binary state of a system

.. by providing static links to dependencies, as Snappy does. Such an approach is wasteful of system resources and goes against the tradition of economy and simplicity in Unix-like operating systems, creating the opportunity for a solution like Guix to provide a more elegant solution.

Guix and the Nix Legacy

Guix is the name of both a collection of package management tools and utilities, and of a distribution (GuixSD) that is on the Free Software Foundation’s list of free distributions. The package manager can be run on any system, independently of any other package manager.

The package manager is based loosely based on Nix. In fact, Ludovic Courtés, Guixs’s maintainer, was once a Nix developer and derived many of the key concepts behind Guix from Nix.

Courtés explains that Guix still uses some low-level code from Nix in its build daemon, but is otherwise different code. The main difference is that while Guix uses the all-purpose language Scheme via GNU Guile to create a unified user and programming interface, Nix uses its own domain-specific language, along with such languages as C++, Bash, and Perl. In addition, Guix has made simpler interfaces one of its priorities.

This difference in direction is explained partly by Guix’s participation in the GNU Project, whose members emphasize free-licensed software. Says Courtés:

Part of our mission is to protect user freedom, and we follow the GNU Free System Distribution Guidelines. A corollary is making sure end users have access to the source that corresponds to the binaries they run. In practical terms, this means shipping only software we can build from source.

This simplicity “is helping us punch above our weight,” says Guix developer Leo Famulari. Although Guix has received little publicity and is often overshadowed by the Canonical and Red Hat publicity departments, between November 2015 and March 2016, fifty-two contributors added 639 packages in five months. Early in 2016, Guix also became the first package manager ported to GNU/Hurd, the GNU Project’s operating system using an alternate kernel.

Package management as a mathematical function

What Guix and Nix continue to share is a conceptual underpinning. Both treat package management is a mathematical function. The results of building a package, for example, depends entirely on the scripts, libraries, and other inputs passed to it, and cannot alter the environment of the system that it is running on. Nor can the process edit files outside of its build and installation directories. Instead, somewhat like Pathogen in Vim, the files for each package are stored in a separate sub-directory of /gnu/store.

This approach has several advantages. For starters, it means that Guix can be installed on any system, just like Snappy and Flatpak.

Just as importantly, if a Guix package installs on one GNU/Linux system, it will install on any other system. For example, Guix developer Ricardo Wurmus has been using Guix on a bioinformatics cluster and user workstations at MDC Berlin for a year and a half:

We can run the very same software on the cluster (running CentOS) as on the workstations (running different versions of Ubuntu, Fedora, and CentOS). When a program works on my machine, I *know* it will just work on the cluster. This is the only solution that lets me (and our scientists) stop worrying too much about reproducing a software environment.

Because packages are isolated, Guix possible makes the installation of different versions without any conflicts. It also allows individual users to install packages themselves, setting up their own view of the /store in their home directory.

Another advantage is that a Guix package is never partially installed. It is either installed or is not, which avoids a common problem in other package management systems like Debian. This arrangement also means that upgrading, and garbage collection (removing unused packages) is more straightforward.

However, according to Guix developer Andreas Enge, probably the most important aspect of Guix is its ability to roll-back packages, reverting to older versions. For example:

I upgrade some software that is essential for my work, the program segfaults, and then I can go back to the previous version within seconds using a single command (guix package --roll-back) instead of wasting the afternoon reinstalling things.

Similarly, wih GuixSD,

The complete system is declared in a text file, [and] a change can be instantiated with one command leading to a new entry in the GNU GRUB boot menu. If a problem occurs, I can simply start the previous configuration again — no more statedful configuration files which are erased by each update. As a consequence, system configurations can be managed in a version control system — the functional aproach ensures that if you put the same configuration out. It may sound abstract at first, but you just need to try it out once to be conquered.

Looking ahead

Currently at release .10, Guix is functional, but still rough at the edges. Although Courtés considers the package manager “mostly ready,” some work still needs to be done. In particular, Courtés would like to see the pull (update) command become more efficient. He would also like to have the GuixSD installation include more of the system services found on the typical server.

Just as importantly, the project is improving its infrastructure. The Free Software Foundation has organized a fundraising campaign for Guix, and the project itself has founded Guix Europe, a non-profit organization registered in France to manage its affairs. With these improvements, the project may finally get some of the attention that it needs.

With the struggle to produce a universal package manager becoming increasingly important, it is important that all the possible contenders receive attention. So far as I can tell, Guix is a more elegant solution than Snappy or Flatpak, and certainly a more-established one.

Yet whatever the technical merits, Guix may be a preferred solution because it is independent, unaligned with either Canonical or Red Hat. Rather than see commercial rivalry spill over into the free software community, perhaps it is better to advocate Guix, with its focus on software freedom — a cause that the makers of the other candidates for a universal package management application can surely agree upon.

---

Cover image by Pete Linforth for Pixabay.com

[sharedaddy]