Webpresence of Philip Kaludercic

Debian with Guix is (un-)surprisingly pleasant!

08 September, 2021

Since Debian 11 (Buster) an interesting new package has been added to the standard repository: guix.

For those unfamiliar, this is referring to GNU Guix, the “liberating, dependable, hackable” functional package manager by the GNU project. Similarly to Nix OS, it can be used as the package manager of a standalone system, or as a supplementary package manager on, that “infects” whatever Linux distribution one might already be running.

The usual way to infect a system would have been to run the installer script. This works, but is slightly more difficult than

# apt install guix
# systemctl enable guix-daemon

(The daemon is a service that is responsible for the managing the packages, but is not that important for now.)

Following this, one should also make sure that the Guix environment will be properly set up. I currently add these lines to ~/.confit/environment.d/:

export GUIX_PROFILE=$HOME/.guix-profile
. "$GUIX_PROFILE/etc/profile"
export PATH=$HOME/.config/guix/current/bin:$PATH

Then run

$ guix pull

to initialize guix for the current user. Depending on your system (shell, window manager, display manager, …), you might have to add the initialize lines somewhere else. The Info node (guix) Application Setup describes further steps that can be taken.

An issue one might encounter is that something like

$ guix install emacs

might take a while. The reason is that Guix is building everything down to the binary seed. You might notice that a lot of time is being spent on building compilers that build other compilers. Some people might be interested in this, anticipating something like a Thompson attack, but I don’t have the resources to do this all the time1. The alternative is to enable “substitutes”, ie. the ability to download pre-build binaries from a server. The root user has to authorize this on infected systems:

# guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub

This vastly improves the usability of the package manager.

The reason Guix (or the also recently release nix-bin package2) is worth trying out is that they make running Debian Stable a lot easier. Traditionally the problem has always been that the Debian prepares a “stable” release, that might work well but becomes outdated quickly. Sometimes the backports system might help to provide newer packages, other times one has no other option than to build from source. And even though Debian Stable is still my preferred distribution3, I always give in a few months before a new release is made and upgrade to “testing”.

Now I can use the stable base, while selecting whatever newer package I am interested in that should be installed via Guix. For example: The newest version of the Go programming language for Debian is [1.15][deb;go], even though 1.16 has been released for a few months now, as of writing4. Using

$ guix install go

I install version 1.165. As new versions are released, the Debian version might become more and more outdated, but Guix can keep me up to date.

It goes without saying, that Guix offers a lot more than just slightly newer versions of some software6. I have not experimented too much with guix environment and other tools yet, but I hope to do so eventually.


  1. By “resources” one doesn’t even have to mean time or computing power. On my system I regularly ran out of disk space, as my root partition is not that large↩︎

  2. Trying out Nix might also be worthwhile, due to its large package selection, but I am more familiar with Guix.↩︎

  3. My last experiment with Guix was not satisfactory enough for me to use the Guix System as my main distribution.↩︎

  4. Interestingly enough even Debian testing and unstable do not provide a newer version. From what I understand this is due to difficulties when building this specific release.↩︎

  5. To be fair, Go 1.17 has been released since, and↩︎

  6. It is probably a design mistake that most distributions don’t have separate repositories for different kinds of software. The stability of the kernel is more important, because more software depends on it than the stability (and conversely the age) a tool like youtube-dl. Using two package managers is a sad but functional workaround.↩︎