Guix Manifests: Package Outputs and Inferiors

Package Outputs in Manifests

This post assumes you are using Guix manifest files (a snazzy feature of Guix) and want to know how to specify a non-default package output. I could not find this documented in the current revision of the Guix info manual. You have to use the procedure specification->package+output. Here is an example which has only a few packages (for readability) but you can have as many packages listed as you want:

 (map (compose list specification->package+output)

The use of specification->package+output allows the specification "transmission:gui" to work. It is necessary to use the compose and list procedures also in this manner, because specification->package+output is a procedure which returns multiple values. (See 6.11.7 Returning and Accepting Multiple Values in the Guile Reference info manual.)


Inferiors are another great feature of Guix, and our documented in the manual. Stated informally, inferiors allow you to list packages from any version of Guix (any commit, or you might say, any time in history) in your manifest file. I use inferiors to install an older version of the linphone software, since I was having some trouble with the latest version. Here is a modification of the above example:

(use-modules (guix inferior)
             (guix channels)
             (srfi srfi-1))

     (define channels
       (list (channel
              (name 'guix)
              (url "")

     (define inferior
       (inferior-for-channels channels))

 (cons (first (lookup-inferior-packages inferior "linphoneqt"))
       (map (compose list specification->package+output)

Now, the linphoneqt package is installed as well from older guix commit 3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5.

Inferiors highlight one of the really awesome aspects of Guix: because guix uses “functional package management”, you can have packages installed in your profile from different versions of Guix, without conflicts or breakages. This would be like if you had the ability in Debian to installation packages from Debian Jessie, Debian Stretch, Debian Buster, and Debian Bullseye without conflicts or breakages. This is not a problem in Guix.[1]

[1] You could conceivably have a run-time conflict, e.g., if the old package depended on a linux kernel feature not available from your running linux kernel. I’ve never run into this sort of problem in any of my use cases. In guix, you don’t have to worry about conflicting package dependencies (e.g., library versions) but of course on a running system there are some services that can only have one version running at a time, the obvious example being the linux kernel. Guix does allow you to have multiple system generations selectable from the bootloader, meaning that you could at least boot into different versions of the linux kernel as would be suitable for running different packages.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s