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:
(packages->manifest (map (compose list specification->package+output) '("abbaye" "emacs" "transmission:gui" "youtube-dl")))
The use of
specification->package+output allows the specification
"transmission:gui" to work. It is necessary to use the
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 "https://git.savannah.gnu.org/git/guix.git") (commit "3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5")))) (define inferior (inferior-for-channels channels)) (packages->manifest (cons (first (lookup-inferior-packages inferior "linphoneqt")) (map (compose list specification->package+output) '("abbaye" "emacs" "transmission:gui" "youtube-dl"))))
linphoneqt package is installed as well from older guix commit
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.
 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.