1.1 Managing Software the Guix Way

Guix provides a command-line package management interface (see Package Management), tools to help with software development (see Development), command-line utilities for more advanced usage (see Utilities), as well as Scheme programming interfaces (see Programming Interface). Its build daemon is responsible for building packages on behalf of users (see Setting Up the Daemon) and for downloading pre-built binaries from authorized sources (see Substitutes).

Guix includes package definitions for many GNU and non-GNU packages, all of which respect the user’s computing freedom. It is extensible: users can write their own package definitions (see Defining Packages) and make them available as independent package modules (see Package Modules). It is also customizable: users can derive specialized package definitions from existing ones, including from the command line (see Package Transformation Options).

Under the hood, Guix implements the functional package management discipline pioneered by Nix (see Acknowledgments). In Guix, the package build and installation process is seen as a function, in the mathematical sense. That function takes inputs, such as build scripts, a compiler, and libraries, and returns an installed package. As a pure function, its result depends solely on its inputs—for instance, it cannot refer to software or scripts that were not explicitly passed as inputs. A build function always produces the same result when passed a given set of inputs. It cannot alter the environment of the running system in any way; for instance, it cannot create, modify, or delete files outside of its build and installation directories. This is achieved by running build processes in isolated environments (or containers), where only their explicit inputs are visible.

The result of package build functions is cached in the file system, in a special directory called the store (see The Store). Each package is installed in a directory of its own in the store—by default under /gnu/store. The directory name contains a hash of all the inputs used to build that package; thus, changing an input yields a different directory name.

This approach is the foundation for the salient features of Guix: support for transactional package upgrade and rollback, per-user installation, and garbage collection of packages (see Features).

1.2 GNU Distribution

Guix comes with a distribution of the GNU system consisting entirely of free software³. The distribution can be installed on its own (see System Installation), but it is also possible to install Guix as a package manager on top of an installed GNU/Linux system (see Installation). When we need to distinguish between the two, we refer to the standalone distribution as Guix System.

The distribution provides core GNU packages such as GNU libc, GCC, and Binutils, as well as many GNU and non-GNU applications. The complete list of available packages can be browsed on-line or by running guix package (see Invoking guix package):

guix package --list-available

Our goal is to provide a practical 100% free software distribution of Linux-based and other variants of GNU, with a focus on the promotion and tight integration of GNU components, and an emphasis on programs and tools that help users exert that freedom.

Packages are currently available on the following platforms:

x86_64-linux

Intel/AMD x86_64 architecture, Linux-Libre kernel.

i686-linux

Intel 32-bit architecture (IA32), Linux-Libre kernel.

armhf-linux

ARMv7-A architecture with hard float, Thumb-2 and NEON, using the EABI hard-float application binary interface (ABI), and Linux-Libre kernel.

aarch64-linux

little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.

i586-gnu

GNU/Hurd on the Intel 32-bit architecture (IA32).

This configuration is experimental and under development. The easiest way for you to give it a try is by setting up an instance of hurd-vm-service-type on your GNU/Linux machine (see hurd-vm-service-type). See Contributing, on how to help!

x86_64-gnu

GNU/Hurd on the x86_64 Intel/AMD 64-bit architecture.

This configuration is even more experimental and under heavy upstream development.

mips64el-linux (unsupported)

little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, there is no ongoing work to ensure that this architecture still works. Should someone decide they wish to revive this architecture then the code is still available.

powerpc-linux (unsupported)

big-endian 32-bit PowerPC processors, specifically the PowerPC G4 with AltiVec support, and Linux-Libre kernel. This configuration is not fully supported and there is no ongoing work to ensure this architecture works.

powerpc64le-linux

little-endian 64-bit Power ISA processors, Linux-Libre kernel. This includes POWER9 systems such as the RYF Talos II mainboard. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (see Substitutes), and some packages may fail to build (see Tracking Bugs and Changes). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved!

riscv64-linux

little-endian 64-bit RISC-V processors, specifically RV64GC, and Linux-Libre kernel. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (see Substitutes), and some packages may fail to build (see Tracking Bugs and Changes). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved!

With Guix System, you declare all aspects of the operating system configuration and Guix takes care of instantiating the configuration in a transactional, reproducible, and stateless fashion (see System Configuration). Guix System uses the Linux-libre kernel, the Shepherd initialization system (see Introduction in The GNU Shepherd Manual), the well-known GNU utilities and tool chain, as well as the graphical environment or system services of your choice.

Guix System is available on all the above platforms except mips64el-linux, powerpc-linux, powerpc64le-linux and riscv64-linux.

For information on porting to other architectures or kernels, see Porting to a New Platform.

Building this distribution is a cooperative effort, and you are invited to join! See Contributing, for information about how you can help.

2.1 Binary Installation

This section describes how to install Guix from a self-contained tarball providing binaries for Guix and for all its dependencies. This is often quicker than installing from source, described later (see Building from Git).

Important: This section only applies to systems without Guix. Following it for existing Guix installations will overwrite important system files.

Some GNU/Linux distributions, such as Debian, Ubuntu, and openSUSE provide Guix through their own package managers. The version of Guix may be older than 84df0c4 but you can update it afterwards by running ‘guix pull’.

We advise system administrators who install Guix, both from the installation script or via the native package manager of their foreign distribution, to also regularly read and follow security notices, as shown by guix pull.

For Debian or derivatives such as Ubuntu or Trisquel, call:

sudo apt install guix

Likewise, on openSUSE:

sudo zypper install guix

If you are running Parabola, after enabling the pcr (Parabola Community Repo) repository, you can install Guix with:

sudo pacman -S guix

The Guix project also provides a shell script, guix-install.sh, which automates the binary installation process without use of a foreign distro package manager⁵. Use of guix-install.sh requires Bash, GnuPG, GNU tar, wget, and Xz.

The script guides you through the following:

• Downloading and extracting the binary tarball
• Setting up the build daemon
• Making the ‘guix’ command available to non-root users
• Configuring substitute servers

As root, run:

# cd /tmp
# wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
# chmod +x guix-install.sh
# ./guix-install.sh

The script to install Guix is also packaged in Parabola (in the pcr repository). You can install and run it with:

sudo pacman -S guix-installer
sudo guix-install.sh

Note: By default, guix-install.sh will configure Guix to download pre-built package binaries, called substitutes (see Substitutes), from the project’s build farms. If you choose not to permit this, Guix will build everything from source, making each installation and upgrade very expensive. See On Trusting Binaries for a discussion of why you may want to build packages from source.

To use substitutes from bordeaux.guix.gnu.org, ci.guix.gnu.org or a mirror, you must authorize them. For example,

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

When you’re done installing Guix, see Application Setup for extra configuration you might need, and Getting Started for your first steps!

Note: The binary installation tarball can be (re)produced and verified simply by running the following command in the Guix source tree:

make guix-binary.system.tar.xz

... which, in turn, runs:

guix pack -s system --localstatedir \
  --profile-name=current-guix guix

See Invoking guix pack, for more info on this handy tool.

Should you eventually want to uninstall Guix, run the same script with the --uninstall flag:

./guix-install.sh --uninstall

With --uninstall, the script irreversibly deletes all the Guix files, configuration, and services.

2.2 Setting Up the Daemon

During installation, the build daemon that must be running to use Guix has already been set up and you can run guix commands in your terminal program, see Getting Started:

guix build hello

If this runs through without error, feel free to skip this section. You should continue with the following section, Application Setup.

However, now would be a good time to replace outdated daemon versions, tweak it, perform builds on other machines (see Using the Offload Facility), or start it manually in special environments like “chroots” (see Chrooting into an existing system) or WSL (not needed for WSL images created with Guix, see wsl2-image-type). If you want to know more or optimize your system, this section is worth reading.

Operations such as building a package or running the garbage collector are all performed by a specialized process, the build daemon, on behalf of clients. Only the daemon may access the store and its associated database. Thus, any operation that manipulates the store goes through the daemon. For instance, command-line tools such as guix package and guix build communicate with the daemon (via remote procedure calls) to instruct it what to do.

The following sections explain how to prepare the build daemon’s environment. See Substitutes for how to allow the daemon to download pre-built binaries.

• Build Environment Setup
• Using the Offload Facility
• SELinux Support

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)   \
            -c "Guix build user $i" --system    \
            guixbuilder$i;
  done

# guix-daemon --build-users-group=guixbuild

(list (build-machine
        (name "eightysix.example.org")
        (systems (list "x86_64-linux" "i686-linux"))
        (host-key "ssh-ed25519 AAAAC3Nza…")
        (user "bob")
        (speed 2.))     ;incredibly fast!

      (build-machine
        (name "armeight.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")

        ;; Remember 'guix offload' is spawned by
        ;; 'guix-daemon' as root.
        (private-key "/root/.ssh/identity-for-guix")))

ssh build-machine guix repl --version

# guix archive --generate-key

# guix archive --authorize < master-public-key.txt

# guix offload test

# guix offload test machines-qualif.scm

# guix offload test machines.scm '\.gnu\.org$'

# guix offload status

semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil

mount -o remount,rw /gnu/store
restorecon -R /gnu /var/guix

systemctl restart guix-daemon

ps -Zax | grep guix-daemon

2.3 Invoking guix-daemon

The guix-daemon program implements all the functionality to access the store. This includes launching build processes, running the garbage collector, querying the availability of a build result, etc. It is normally run as root like this:

# guix-daemon --build-users-group=guixbuild

This daemon can also be started following the systemd “socket activation” protocol (see make-systemd-constructor in The GNU Shepherd Manual).

For details on how to set it up, see Setting Up the Daemon.

By default, guix-daemon launches build processes under different UIDs, taken from the build group specified with --build-users-group. In addition, each build process is run in a chroot environment that only contains the subset of the store that the build process depends on, as specified by its derivation (see derivation), plus a set of specific system directories. By default, the latter contains /dev and /dev/pts. Furthermore, on GNU/Linux, the build environment is a container: in addition to having its own file system tree, it has a separate mount name space, its own PID name space, network name space, etc. This helps achieve reproducible builds (see Features).

When the daemon performs a build on behalf of the user, it creates a build directory under /tmp or under the directory specified by its TMPDIR environment variable. This directory is shared with the container for the duration of the build, though within the container, the build tree is always called /tmp/guix-build-name.drv-0.

The build directory is automatically deleted upon completion, unless the build failed and the client specified --keep-failed (see --keep-failed).

The daemon listens for connections and spawns one sub-process for each session started by a client (one of the guix sub-commands). The guix processes command allows you to get an overview of the activity on your system by viewing each of the active sessions and clients. See Invoking guix processes, for more information.

The following command-line options are supported:

--build-users-group=group

Take users from group to run build processes (see build users).

--no-substitutes ¶

Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (see Substitutes).

When the daemon runs with --no-substitutes, clients can still explicitly enable substitution via the set-build-options remote procedure call (see The Store).

--substitute-urls=urls

Consider urls the default whitespace-separated list of substitute source URLs. When this option is omitted, ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org’ is used.

This means that substitutes may be downloaded from urls, as long as they are signed by a trusted signature (see Substitutes).

See Getting Substitutes from Other Servers, for more information on how to configure the daemon to get substitutes from other servers.

--no-offload

Do not use offload builds to other machines (see Using the Offload Facility). That is, always build things locally instead of offloading builds to remote machines.

--cache-failures

Cache build failures. By default, only successful builds are cached.

When this option is used, guix gc --list-failures can be used to query the set of store items marked as failed; guix gc --clear-failures removes store items from the set of cached failures. See Invoking guix gc.

--cores=n

-c n

Use n CPU cores to build each derivation; 0 means as many as available.

The default value is 0, but it may be overridden by clients, such as the --cores option of guix build (see Invoking guix build).

The effect is to define the NIX_BUILD_CORES environment variable in the build process, which can then use it to exploit internal parallelism—for instance, by running make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Allow at most n build jobs in parallel. The default value is 1. Setting it to 0 means that no builds will be performed locally; instead, the daemon will offload builds (see Using the Offload Facility), or simply fail.

--max-silent-time=seconds

When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.

The default value is 3600 (one hour).

The value specified here can be overridden by clients (see --max-silent-time).

--timeout=seconds

Likewise, when the build or substitution process lasts for more than seconds, terminate it and report a build failure.

The default value is 24 hours.

The value specified here can be overridden by clients (see --timeout).

--rounds=N

Build each derivation n times in a row, and raise an error if consecutive build results are not bit-for-bit identical. Note that this setting can be overridden by clients such as guix build (see Invoking guix build).

When used in conjunction with --keep-failed, the differing output is kept in the store, under /gnu/store/…-check. This makes it easy to look for differences between the two results.

--debug

Produce debugging output.

This is useful to debug daemon start-up issues, but then it may be overridden by clients, for example the --verbosity option of guix build (see Invoking guix build).

--chroot-directory=dir

Add dir to the build chroot.

Doing this may change the result of build processes—for instance if they use optional dependencies found in dir when it is available, and not otherwise. For that reason, it is not recommended to do so. Instead, make sure that each derivation declares all the inputs that it needs.

--disable-chroot

Disable chroot builds.

Using this option is not recommended since, again, it would allow build processes to gain access to undeclared dependencies. It is necessary, though, when guix-daemon is running under an unprivileged user account.

--log-compression=type

Compress build logs according to type, one of gzip, bzip2, or none.

Unless --lose-logs is used, all the build logs are kept in the localstatedir. To save space, the daemon automatically compresses them with gzip by default.

--discover[=yes|no]

Whether to discover substitute servers on the local network using mDNS and DNS-SD.

This feature is still experimental. However, here are a few considerations.

1. It might be faster/less expensive than fetching from remote servers;
2. There are no security risks, only genuine substitutes will be used (see Substitute Authentication);
3. An attacker advertising guix publish on your LAN cannot serve you malicious binaries, but they can learn what software you’re installing;
4. Servers may serve substitute over HTTP, unencrypted, so anyone on the LAN can see what software you’re installing.

It is also possible to enable or disable substitute server discovery at run-time by running:

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication ¶

Disable automatic file “deduplication” in the store.

By default, files added to the store are automatically “deduplicated”: if a newly added file is identical to another one found in the store, the daemon makes the new file a hard link to the other file. This can noticeably reduce disk usage, at the expense of slightly increased input/output load at the end of a build process. This option disables this optimization.

--gc-keep-outputs[=yes|no]

Tell whether the garbage collector (GC) must keep outputs of live derivations.

When set to yes, the GC will keep the outputs of any live derivation available in the store—the .drv files. The default is no, meaning that derivation outputs are kept only if they are reachable from a GC root. See Invoking guix gc, for more on GC roots.

--gc-keep-derivations[=yes|no]

Tell whether the garbage collector (GC) must keep derivations corresponding to live outputs.

When set to yes, as is the case by default, the GC keeps derivations—i.e., .drv files—as long as at least one of their outputs is live. This allows users to keep track of the origins of items in their store. Setting it to no saves a bit of disk space.

In this way, setting --gc-keep-derivations to yes causes liveness to flow from outputs to derivations, and setting --gc-keep-outputs to yes causes liveness to flow from derivations to outputs. When both are set to yes, the effect is to keep all the build prerequisites (the sources, compiler, libraries, and other build-time tools) of live objects in the store, regardless of whether these prerequisites are reachable from a GC root. This is convenient for developers since it saves rebuilds or downloads.

--impersonate-linux-2.6

On Linux-based systems, impersonate Linux 2.6. This means that the kernel’s uname system call will report 2.6 as the release number.

This might be helpful to build programs that (usually wrongfully) depend on the kernel version number.

--lose-logs

Do not keep build logs. By default they are kept under localstatedir/guix/log.

--system=system

Assume system as the current system type. By default it is the architecture/kernel pair found at configure time, such as x86_64-linux.

--listen=endpoint

Listen for connections on endpoint. endpoint is interpreted as the file name of a Unix-domain socket if it starts with / (slash sign). Otherwise, endpoint is interpreted as a host name or host name and port to listen to. Here are a few examples:

--listen=/gnu/var/daemon

Listen for connections on the /gnu/var/daemon Unix-domain socket, creating it if needed.

--listen=localhost ¶

Listen for TCP connections on the network interface corresponding to localhost, on port 44146.

--listen=128.0.0.42:1234

Listen for TCP connections on the network interface corresponding to 128.0.0.42, on port 1234.

This option can be repeated multiple times, in which case guix-daemon accepts connections on all the specified endpoints. Users can tell client commands what endpoint to connect to by setting the GUIX_DAEMON_SOCKET environment variable (see GUIX_DAEMON_SOCKET).

Note: The daemon protocol is unauthenticated and unencrypted. Using --listen=host is suitable on local networks, such as clusters, where only trusted nodes may connect to the build daemon. In other cases where remote access to the daemon is needed, we recommend using Unix-domain sockets along with SSH.

When --listen is omitted, guix-daemon listens for connections on the Unix-domain socket located at localstatedir/guix/daemon-socket/socket.

2.4 Application Setup

When using Guix on top of GNU/Linux distribution other than Guix System—a so-called foreign distro—a few additional steps are needed to get everything in place. Here are some of them.

• Locales
• Name Service Switch
• X11 Fonts
• X.509 Certificates
• Emacs Packages

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-locales"))

guix install fontconfig
fc-cache -rv

guix install font-adobe-source-han-sans:cn

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

2.5 Upgrading Guix

To upgrade Guix, run:

guix pull

See Invoking guix pull, for more information.

On a foreign distro, you can upgrade the build daemon by running:

sudo -i guix pull

followed by (assuming your distro uses the systemd service management tool):

systemctl restart guix-daemon.service

On Guix System, upgrading the daemon is achieved by reconfiguring the system (see guix system reconfigure).

3.1 Limitations

We consider Guix System to be ready for a wide range of “desktop” and server use cases. The reliability guarantees it provides—transactional upgrades and rollbacks, reproducibility—make it a solid foundation.

More and more system services are provided (see Services).

Nevertheless, before you proceed with the installation, be aware that some services you rely on may still be missing from version 84df0c4.

More than a disclaimer, this is an invitation to report issues (and success stories!), and to join us in improving it. See Contributing, for more info.

3.2 Hardware Considerations

GNU Guix focuses on respecting the user’s computing freedom. It builds around the kernel Linux-libre, which means that only hardware for which free software drivers and firmware exist is supported. Nowadays, a wide range of off-the-shelf hardware is supported on GNU/Linux-libre—from keyboards to graphics cards to scanners and Ethernet controllers. Unfortunately, there are still areas where hardware vendors deny users control over their own computing, and such hardware is not supported on Guix System.

One of the main areas where free drivers or firmware are lacking is WiFi devices. WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the ath9k Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the b43-open Linux-libre driver. Free firmware exists for both and is available out-of-the-box on Guix System, as part of %base-firmware (see firmware).

The installer warns you early on if it detects devices that are known not to work due to the lack of free firmware or free drivers.

The Free Software Foundation runs Respects Your Freedom (RYF), a certification program for hardware products that respect your freedom and your privacy and ensure that you have control over your device. We encourage you to check the list of RYF-certified devices.

Another useful resource is the H-Node web site. It contains a catalog of hardware devices with information about their support in GNU/Linux.

3.3 USB Stick and DVD Installation

An ISO-9660 installation image that can be written to a USB stick or burnt to a DVD can be downloaded from ‘https://ftp.gnu.org/gnu/guix/guix-system-install-84df0c4.x86_64-linux.iso’, where you can replace x86_64-linux with one of:

x86_64-linux

for a GNU/Linux system on Intel/AMD-compatible 64-bit CPUs;

i686-linux

for a 32-bit GNU/Linux system on Intel-compatible CPUs.

Make sure to download the associated .sig file and to verify the authenticity of the image against it, along these lines:

$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-84df0c4.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-84df0c4.x86_64-linux.iso.sig

If that command fails because you do not have the required public key, then run this command to import it:

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 \
      -qO - | gpg --import -

and rerun the gpg --verify command.

Take note that a warning like “This key is not certified with a trusted signature!” is normal.

This image contains the tools necessary for an installation. It is meant to be copied as is to a large-enough USB stick or DVD.

• Copying to a USB Stick
• Burning on a DVD
• Booting

dd if=guix-system-install-84df0c4.x86_64-linux.iso of=/dev/sdX status=progress
sync

growisofs -dvd-compat -Z /dev/srX=guix-system-install-84df0c4.x86_64-linux.iso

3.4 Preparing for Installation

Once you have booted, you can use the guided graphical installer, which makes it easy to get started (see Guided Graphical Installation). Alternatively, if you are already familiar with GNU/Linux and if you want more control than what the graphical installer provides, you can choose the “manual” installation process (see Manual Installation).

The graphical installer is available on TTY1. You can obtain root shells on TTYs 3 to 6 by hitting ctrl-alt-f3, ctrl-alt-f4, etc. TTY2 shows this documentation and you can reach it with ctrl-alt-f2. Documentation is browsable using the Info reader commands (see Stand-alone GNU Info). The installation system runs the GPM mouse daemon, which allows you to select text with the left mouse button and to paste it with the middle button.

Note: Installation requires access to the Internet so that any missing dependencies of your system configuration can be downloaded. See the “Networking” section below.

3.5 Guided Graphical Installation

The graphical installer is a text-based user interface. It will guide you, with dialog boxes, through the steps needed to install GNU Guix System.

The first dialog boxes allow you to set up the system as you use it during the installation: you can choose the language, keyboard layout, and set up networking, which will be used during the installation. The image below shows the networking dialog.

Later steps allow you to partition your hard disk, as shown in the image below, to choose whether or not to use encrypted file systems, to enter the host name and root password, and to create an additional account, among other things.

Note that, at any time, the installer allows you to exit the current installation step and resume at a previous step, as show in the image below.

Once you’re done, the installer produces an operating system configuration and displays it (see Using the Configuration System). At that point you can hit “OK” and installation will proceed. On success, you can reboot into the new system and enjoy. See After System Installation, for what’s next!

3.6 Manual Installation

This section describes how you would “manually” install GNU Guix System on your machine. This option requires familiarity with GNU/Linux, with the shell, and with common administration tools. If you think this is not for you, consider using the guided graphical installer (see Guided Graphical Installation).

The installation system provides root shells on TTYs 3 to 6; press ctrl-alt-f3, ctrl-alt-f4, and so on to reach them. It includes many common tools needed to install the system, but is also a full-blown Guix System. This means that you can install additional packages, should you need it, using guix package (see Invoking guix package).

• Keyboard Layout, Networking, and Partitioning
• Proceeding with the Installation

loadkeys dvorak

ifconfig -a

ip address

dhclient -v interface

ping -c 3 gnu.org

herd set-http-proxy guix-daemon URL

herd start ssh-daemon

cfdisk

parted /dev/sda set 1 esp on

mkfs.fat -F32 /dev/sda1

mkfs.ext4 -L my-root /dev/sda2

cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

mount LABEL=my-root /mnt

mkswap /dev/sda3
swapon /dev/sda3

# This is 10 GiB of swap space.  Adjust "count" to change the size.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# For security, make the file readable and writable only by root.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

herd start cow-store /mnt

# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm

guix system init /mnt/etc/config.scm /mnt

3.7 After System Installation

Success, you’ve now booted into Guix System! You can upgrade the system whenever you want by running:

guix pull
sudo guix system reconfigure /etc/config.scm

This builds a new system generation with the latest packages and services.

Now, see Getting Started, and join us on #guix on the Libera.Chat IRC network or on guix-devel@gnu.org to share your experience!

3.8 Installing Guix in a Virtual Machine

If you’d like to install Guix System in a virtual machine (VM) or on a virtual private server (VPS) rather than on your beloved machine, this section is for you.

To boot a QEMU VM for installing Guix System in a disk image, follow these steps:

1. First, retrieve and decompress the Guix system installation image as described previously (see USB Stick and DVD Installation).
2. Create a disk image that will hold the installed system. To make a qcow2-formatted disk image, use the qemu-img command:

   qemu-img create -f qcow2 guix-system.img 50G
   

   The resulting file will be much smaller than 50 GB (typically less than 1 MB), but it will grow as the virtualized storage device is filled up.

3. Boot the USB installation image in a VM:

   qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
     -nic user,model=virtio-net-pci -boot menu=on,order=d \
     -drive file=guix-system.img \
     -drive media=cdrom,readonly=on,file=guix-system-install-84df0c4.system.iso
   

   -enable-kvm is optional, but significantly improves performance, see Running Guix in a Virtual Machine.

4. You’re now root in the VM, proceed with the installation process. See Preparing for Installation, and follow the instructions.

Once installation is complete, you can boot the system that’s on your guix-system.img image. See Running Guix in a Virtual Machine, for how to do that.

3.9 Building the Installation Image

The installation image described above was built using the guix system command, specifically:

guix system image -t iso9660 gnu/system/install.scm

Have a look at gnu/system/install.scm in the source tree, and see also Invoking guix system for more information about the installation image.

3.10 Building the Installation Image for ARM Boards

Many ARM boards require a specific variant of the U-Boot bootloader.

If you build a disk image and the bootloader is not available otherwise (on another boot drive etc), it’s advisable to build an image that includes the bootloader, specifically:

guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 is the name of the board. If you specify an invalid board, a list of possible boards will be printed.

5.1 Features

Here we assume you’ve already made your first steps with Guix (see Getting Started) and would like to get an overview about what’s going on under the hood.

When using Guix, each package ends up in the package store, in its own directory—something that resembles /gnu/store/xxx-package-1.2, where xxx is a base32 string.

Instead of referring to these directories, users have their own profile, which points to the packages that they actually want to use. These profiles are stored within each user’s home directory, at $HOME/.guix-profile.

For example, alice installs GCC 4.7.2. As a result, /home/alice/.guix-profile/bin/gcc points to /gnu/store/…-gcc-4.7.2/bin/gcc. Now, on the same machine, bob had already installed GCC 4.8.0. The profile of bob simply continues to point to /gnu/store/…-gcc-4.8.0/bin/gcc—i.e., both versions of GCC coexist on the same system without any interference.

The guix package command is the central tool to manage packages (see Invoking guix package). It operates on the per-user profiles, and can be used with normal user privileges.

The command provides the obvious install, remove, and upgrade operations. Each invocation is actually a transaction: either the specified operation succeeds, or nothing happens. Thus, if the guix package process is terminated during the transaction, or if a power outage occurs during the transaction, then the user’s profile remains in its previous state, and remains usable.

In addition, any package transaction may be rolled back. So, if, for example, an upgrade installs a new version of a package that turns out to have a serious bug, users may roll back to the previous instance of their profile, which was known to work well. Similarly, the global system configuration on Guix is subject to transactional upgrades and roll-back (see Getting Started).

All packages in the package store may be garbage-collected. Guix can determine which packages are still referenced by user profiles, and remove those that are provably no longer referenced (see Invoking guix gc). Users may also explicitly remove old generations of their profile so that the packages they refer to can be collected.

Guix takes a purely functional approach to package management, as described in the introduction (see Introduction). Each /gnu/store package directory name contains a hash of all the inputs that were used to build that package—compiler, libraries, build scripts, etc. This direct correspondence allows users to make sure a given package installation matches the current state of their distribution. It also helps maximize build reproducibility: thanks to the isolated build environments that are used, a given build is likely to yield bit-identical files when performed on different machines (see container).

This foundation allows Guix to support transparent binary/source deployment. When a pre-built binary for a /gnu/store item is available from an external source—a substitute, Guix just downloads it and unpacks it; otherwise, it builds the package from source, locally (see Substitutes). Because build results are usually bit-for-bit reproducible, users do not have to trust servers that provide substitutes: they can force a local build and challenge providers (see Invoking guix challenge).

Control over the build environment is a feature that is also useful for developers. The guix shell command allows developers of a package to quickly set up the right development environment for their package, without having to manually install the dependencies of the package into their profile (see Invoking guix shell).

All of Guix and its package definitions is version-controlled, and guix pull allows you to “travel in time” on the history of Guix itself (see Invoking guix pull). This makes it possible to replicate a Guix instance on a different machine or at a later point in time, which in turn allows you to replicate complete software environments, while retaining precise provenance tracking of the software.

5.2 Invoking guix package

The guix package command is the tool that allows users to install, upgrade, and remove packages, as well as rolling back to previous configurations. These operations work on a user profile—a directory of installed packages. Each user has a default profile in $HOME/.guix-profile. The command operates only on the user’s own profile, and works with normal user privileges (see Features). Its syntax is:

guix package options

Primarily, options specifies the operations to be performed during the transaction. Upon completion, a new profile is created, but previous generations of the profile remain available, should the user want to roll back.

For example, to remove lua and install guile and guile-cairo in a single transaction:

guix package -r lua -i guile guile-cairo

For your convenience, we also provide the following aliases:

• guix search is an alias for guix package -s,
• guix install is an alias for guix package -i,
• guix remove is an alias for guix package -r,
• guix upgrade is an alias for guix package -u,
• and guix show is an alias for guix package --show=.

These aliases are less expressive than guix package and provide fewer options, so in some cases you’ll probably want to use guix package directly.

guix package also supports a declarative approach whereby the user specifies the exact set of packages to be available and passes it via the --manifest option (see --manifest).

For each user, a symlink to the user’s default profile is automatically created in $HOME/.guix-profile. This symlink always points to the current generation of the user’s default profile. Thus, users can add $HOME/.guix-profile/bin to their PATH environment variable, and so on. If you are not using Guix System, consider adding the following lines to your ~/.bash_profile (see Bash Startup Files in The GNU Bash Reference Manual) so that newly-spawned shells get all the right environment variable definitions:

GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$GUIX_PROFILE/etc/profile"

In a multi-user setup, user profiles are stored in a place registered as a garbage-collector root, which $HOME/.guix-profile points to (see Invoking guix gc). That directory is normally localstatedir/guix/profiles/per-user/user, where localstatedir is the value passed to configure as --localstatedir, and user is the user name. The per-user directory is created when guix-daemon is started, and the user sub-directory is created by guix package.

The options can be among the following:

--install=package …

-i package …

Install the specified packages.

Each package may specify a simple package name, such as guile, optionally followed by an at-sign and version number, such as guile@3.0.7 or simply guile@3.0. In the latter case, the newest version prefixed by 3.0 is selected.

If no version number is specified, the newest available version will be selected. In addition, such a package specification may contain a colon, followed by the name of one of the outputs of the package, as in gcc:doc or binutils@2.22:lib (see Packages with Multiple Outputs).

Packages with a corresponding name (and optionally version) are searched for among the GNU distribution modules (see Package Modules).

Alternatively, a package can directly specify a store file name such as /gnu/store/...-guile-3.0.7, as produced by, e.g., guix build.

Sometimes packages have propagated inputs: these are dependencies that automatically get installed along with the required package (see propagated-inputs in package objects, for information about propagated inputs in package definitions).

An example is the GNU MPC library: its C header files refer to those of the GNU MPFR library, which in turn refer to those of the GMP library. Thus, when installing MPC, the MPFR and GMP libraries also get installed in the profile; removing MPC also removes MPFR and GMP—unless they had also been explicitly installed by the user.

Besides, packages sometimes rely on the definition of environment variables for their search paths (see explanation of --search-paths below). Any missing or possibly incorrect environment variable definitions are reported here.

--install-from-expression=exp

-e exp

Install the package exp evaluates to.

exp must be a Scheme expression that evaluates to a <package> object. This option is notably useful to disambiguate between same-named variants of a package, with expressions such as (@ (gnu packages commencement) guile-final).

Note that this option installs the first output of the specified package, which may be insufficient when needing a specific output of a multiple-output package.

--install-from-file=file

-f file

Install the package that the code within file evaluates to.

As an example, file might contain a definition like this (see Defining Packages):

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Developers may find it useful to include such a guix.scm file in the root of their project source tree that can be used to test development snapshots and create reproducible development environments (see Invoking guix shell).

The file may also contain a JSON representation of one or more package definitions. Running guix package -f on hello.json with the following contents would result in installing the package greeter after building myhello:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    },
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]

--remove=package …

-r package …

Remove the specified packages.

As for --install, each package may specify a version number and/or output name in addition to the package name. For instance, ‘-r glibc:debug’ would remove the debug output of glibc.

--upgrade[=regexp …] ¶

-u [regexp …]

Upgrade all the installed packages. If one or more regexps are specified, upgrade only installed packages whose name matches a regexp. Also see the --do-not-upgrade option below.

Note that this upgrades package to the latest version of packages found in the distribution currently installed. To update your distribution, you should regularly run guix pull (see Invoking guix pull).

When upgrading, package transformations that were originally applied when creating the profile are automatically re-applied (see Package Transformation Options). For example, assume you first installed Emacs from the tip of its development branch with:

guix install emacs-next --with-branch=emacs-next=master

Next time you run guix upgrade, Guix will again pull the tip of the Emacs development branch and build emacs-next from that checkout.

Note that transformation options such as --with-branch and --with-source depend on external state; it is up to you to ensure that they work as expected. You can also discard a transformations that apply to a package by running:

guix install package

--do-not-upgrade[=regexp …]

When used together with the --upgrade option, do not upgrade any packages whose name matches a regexp. For example, to upgrade all packages in the current profile except those containing the substring “emacs”:

$ guix package --upgrade . --do-not-upgrade emacs

--manifest=file ¶

-m file

Create a new generation of the profile from the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

This allows you to declare the profile’s contents rather than constructing it through a sequence of --install and similar commands. The advantage is that file can be put under version control, copied to different machines to reproduce the same profile, and so on.

file must return a manifest object, which is roughly a list of packages:

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Use a specific package output.
       (list guile-2.0 "debug")))

See Writing Manifests, for information on how to write a manifest. See --export-manifest, to learn how to obtain a manifest file from an existing profile.

--roll-back ¶

Roll back to the previous generation of the profile—i.e., undo the last transaction.

When combined with options such as --install, roll back occurs before any other actions.

When rolling back from the first generation that actually contains installed packages, the profile is made to point to the zeroth generation, which contains no files apart from its own metadata.

After having rolled back, installing, removing, or upgrading packages overwrites previous future generations. Thus, the history of the generations in a profile is always linear.

--switch-generation=pattern ¶

-S pattern

Switch to a particular generation defined by pattern.

pattern may be either a generation number or a number prefixed with “+” or “-”. The latter means: move forward/backward by a specified number of generations. For example, if you want to return to the latest generation after --roll-back, use --switch-generation=+1.

The difference between --roll-back and --switch-generation=-1 is that --switch-generation will not make a zeroth generation, so if a specified generation does not exist, the current generation will not be changed.

--search-paths[=kind] ¶

Report environment variable definitions, in Bash syntax, that may be needed in order to use the set of installed packages. These environment variables are used to specify search paths for files used by some of the installed packages.

For example, GCC needs the CPATH and LIBRARY_PATH environment variables to be defined so it can look for headers and libraries in the user’s profile (see Environment Variables in Using the GNU Compiler Collection (GCC)). If GCC and, say, the C library are installed in the profile, then --search-paths will suggest setting these variables to profile/include and profile/lib, respectively (see Search Paths, for info on search path specifications associated with packages.)

The typical use case is to define these environment variables in the shell:

$ eval $(guix package --search-paths)

kind may be one of exact, prefix, or suffix, meaning that the returned environment variable definitions will either be exact settings, or prefixes or suffixes of the current value of these variables. When omitted, kind defaults to exact.

This option can also be used to compute the combined search paths of several profiles. Consider this example:

$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths

The last command above reports about the GUILE_LOAD_PATH variable, even though, taken individually, neither foo nor bar would lead to that recommendation.

--profile=profile

-p profile

Use profile instead of the user’s default profile.

profile must be the name of a file that will be created upon completion. Concretely, profile will be a mere symbolic link (“symlink”) pointing to the actual profile where packages are installed:

$ guix install hello -p ~/code/my-profile
…
$ ~/code/my-profile/bin/hello
Hello, world!

All it takes to get rid of the profile is to remove this symlink and its siblings that point to specific generations:

$ rm ~/code/my-profile ~/code/my-profile-*-link

--list-profiles

List all the user’s profiles:

$ guix package --list-profiles
/home/charlie/.guix-profile
/home/charlie/code/my-profile
/home/charlie/code/devel-profile
/home/charlie/tmp/test

When running as root, list all the profiles of all the users.

--allow-collisions

Allow colliding packages in the new profile. Use at your own risk!

By default, guix package reports as an error collisions in the profile. Collisions happen when two or more different versions or variants of a given package end up in the profile.

--bootstrap

Use the bootstrap Guile to build the profile. This option is only useful to distribution developers.

In addition to these actions, guix package supports the following options to query the current state of a profile, or the availability of packages:

--search=regexp

-s regexp

List the available packages whose name, synopsis, or description matches regexp (in a case-insensitive fashion), sorted by relevance. Print all the metadata of matching packages in recutils format (see GNU recutils databases in GNU recutils manual).

This allows specific fields to be extracted using the recsel command, for instance:

$ guix package -s malloc | recsel -p name,version,relevance
name: jemalloc
version: 4.5.0
relevance: 6

name: glibc
version: 2.25
relevance: 1

name: libgc
version: 7.6.0
relevance: 1

Similarly, to show the name of all the packages available under the terms of the GNU LGPL version 3:

$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils

name: gmp
…

It is also possible to refine search results using several -s flags to guix package, or several arguments to guix search. For example, the following command returns a list of board games (this time using the guix search alias):

$ guix search '\<board\>' game | recsel -p name
name: gnubg
…

If we were to omit -s game, we would also get software packages that deal with printed circuit boards; removing the angle brackets around board would further add packages that have to do with keyboards.

And now for a more elaborate example. The following command searches for cryptographic libraries, filters out Haskell, Perl, Python, and Ruby libraries, and prints the name and synopsis of the matching packages:

$ guix search crypto library | \
    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

See Selection Expressions in GNU recutils manual, for more information on selection expressions for recsel -e.

--show=package

Show details about package, taken from the list of available packages, in recutils format (see GNU recutils databases in GNU recutils manual).

$ guix package --show=guile | recsel -p name,version
name: guile
version: 3.0.5

name: guile
version: 3.0.2

name: guile
version: 2.2.7
…

You may also specify the full name of a package to only get details about a specific version of it (this time using the guix show alias):

$ guix show guile@3.0.5 | recsel -p name,version
name: guile
version: 3.0.5

--list-installed[=regexp]

-I [regexp]

List the currently installed packages in the specified profile, with the most recently installed packages shown last. When regexp is specified, list only installed packages whose name matches regexp.

For each installed package, print the following items, separated by tabs: the package name, its version string, the part of the package that is installed (for instance, out for the default output, include for its headers, etc.), and the path of this package in the store.

--list-available[=regexp]

-A [regexp]

List packages currently available in the distribution for this system (see GNU Distribution). When regexp is specified, list only available packages whose name matches regexp.

For each package, print the following items separated by tabs: its name, its version string, the parts of the package (see Packages with Multiple Outputs), and the source location of its definition.

--list-generations[=pattern] ¶

-l [pattern]

Return a list of generations along with their creation dates; for each generation, show the installed packages, with the most recently installed packages shown last. Note that the zeroth generation is never shown.

For each installed package, print the following items, separated by tabs: the name of a package, its version string, the part of the package that is installed (see Packages with Multiple Outputs), and the location of this package in the store.

When pattern is used, the command returns only matching generations. Valid patterns include:

• Integers and comma-separated integers. Both patterns denote generation numbers. For instance, --list-generations=1 returns the first one.

  And --list-generations=1,8,2 outputs three generations in the specified order. Neither spaces nor trailing commas are allowed.

• Ranges. --list-generations=2..9 prints the specified generations and everything in between. Note that the start of a range must be smaller than its end.

  It is also possible to omit the endpoint. For example, --list-generations=2.., returns all generations starting from the second one.

• Durations. You can also get the last N days, weeks, or months by passing an integer along with the first letter of the duration. For example, --list-generations=20d lists generations that are up to 20 days old.

--delete-generations[=pattern]

-d [pattern]

When pattern is omitted, delete all generations except the current one.

This command accepts the same patterns as --list-generations. When pattern is specified, delete the matching generations. When pattern specifies a duration, generations older than the specified duration match. For instance, --delete-generations=1m deletes generations that are more than one month old.

If the current generation matches, it is not deleted. Also, the zeroth generation is never deleted.

Note that deleting generations prevents rolling back to them. Consequently, this command must be used with care.

--export-manifest

Write to standard output a manifest suitable for --manifest corresponding to the chosen profile(s).

This option is meant to help you migrate from the “imperative” operating mode—running guix install, guix upgrade, etc.—to the declarative mode that --manifest offers.

Be aware that the resulting manifest approximates what your profile actually contains; for instance, depending on how your profile was created, it can refer to packages or package versions that are not exactly what you specified.

Keep in mind that a manifest is purely symbolic: it only contains package names and possibly versions, and their meaning varies over time. If you wish to “pin” channels to the revisions that were used to build the profile(s), see --export-channels below.

--export-channels

Write to standard output the list of channels used by the chosen profile(s), in a format suitable for guix pull --channels or guix time-machine --channels (see Channels).

Together with --export-manifest, this option provides information allowing you to replicate the current profile (see Replicating Guix).

However, note that the output of this command approximates what was actually used to build this profile. In particular, a single profile might have been built from several different revisions of the same channel. In that case, --export-manifest chooses the last one and writes the list of other revisions in a comment. If you really need to pick packages from different channel revisions, you can use inferiors in your manifest to do so (see Inferiors).

Together with --export-manifest, this is a good starting point if you are willing to migrate from the “imperative” model to the fully declarative model consisting of a manifest file along with a channels file pinning the exact channel revision(s) you want.

Finally, since guix package may actually start build processes, it supports all the common build options (see Common Build Options). It also supports package transformation options, such as --with-source, and preserves them across upgrades (see Package Transformation Options).

5.3 Substitutes

Guix supports transparent source/binary deployment, which means that it can either build things locally, or download pre-built items from a server, or both. We call these pre-built items substitutes—they are substitutes for local build results. In many cases, downloading a substitute is much faster than building things locally.

Substitutes can be anything resulting from a derivation build (see Derivations). Of course, in the common case, they are pre-built package binaries, but source tarballs, for instance, which also result from derivation builds, can be available as substitutes.

• Official Substitute Servers
• Substitute Server Authorization
• Getting Substitutes from Other Servers
• Substitute Authentication
• Proxy Settings
• Substitution Failure
• On Trusting Binaries

# guix archive --authorize < prefix/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub

$ guix build emacs --dry-run
The following derivations would be built:
   /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
   /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
   /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
   /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
…

$ guix build emacs --dry-run
112.3 MB would be downloaded:
   /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
   /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
   /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
   /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
…

(operating-system
  ;; …
  (services
    ;; Assume we're starting from '%desktop-services'.  Replace it
    ;; with the list of services you're actually using.
    (modify-services %desktop-services
      (guix-service-type config =>
                        (guix-configuration
                          (inherit config)
                          (substitute-urls
                            (append (list "https://guix.example.org")
                                    %default-substitute-urls))
                          (authorized-keys
                            (append (list (local-file "./key.pub"))
                                    %default-authorized-guix-keys)))))))

$ sudo guix system reconfigure /etc/config.scm
$ sudo herd restart guix-daemon

--substitute-urls="https://a.example.org https://b.example.org"

5.4 Packages with Multiple Outputs

Often, packages defined in Guix have a single output—i.e., the source package leads to exactly one directory in the store. When running guix install glibc, one installs the default output of the GNU libc package; the default output is called out, but its name can be omitted as shown in this command. In this particular case, the default output of glibc contains all the C header files, shared libraries, static libraries, Info documentation, and other supporting files.

Sometimes it is more appropriate to separate the various types of files produced from a single source package into separate outputs. For instance, the GLib C library (used by GTK+ and related packages) installs more than 20 MiB of reference documentation as HTML pages. To save space for users who do not need it, the documentation goes to a separate output, called doc. To install the main GLib output, which contains everything but the documentation, one would run:

guix install glib

The command to install its documentation is:

guix install glib:doc

While the colon syntax works for command-line specification of package outputs, it will not work when using a package variable in Scheme code. For example, to add the documentation of glib to the globally installed packages of an operating-system (see operating-system Reference), a list of two items, the first one being the package variable and the second one the name of the output to select (a string), must be used instead:

(use-modules (gnu packages glib))
;; glib-with-documentation is the Guile symbol for the glib package
(operating-system
 ...
 (packages
  (append
   (list (list glib-with-documentation "doc"))
         %base-packages)))

Some packages install programs with different “dependency footprints”. For instance, the WordNet package installs both command-line tools and graphical user interfaces (GUIs). The former depend solely on the C library, whereas the latter depend on Tcl/Tk and the underlying X libraries. In this case, we leave the command-line tools in the default output, whereas the GUIs are in a separate output. This allows users who do not need the GUIs to save space. The guix size command can help find out about such situations (see Invoking guix size). guix graph can also be helpful (see Invoking guix graph).

There are several such multiple-output packages in the GNU distribution. Other conventional output names include lib for libraries and possibly header files, bin for stand-alone programs, and debug for debugging information (see Installing Debugging Files). The outputs of a package are listed in the third column of the output of guix package --list-available (see Invoking guix package).

5.5 Invoking guix locate

There’s so much free software out there that sooner or later, you will need to search for packages. The guix search command that we’ve seen before (see Invoking guix package) lets you search by keywords:

guix search video editor

Sometimes, you instead want to find which package provides a given file, and this is where guix locate comes in. Here is how you can find which package provides the ls command:

$ guix locate ls
coreutils@9.1       /gnu/store/…-coreutils-9.1/bin/ls

Of course the command works for any file, not just commands:

$ guix locate unistr.h
icu4c@71.1          /gnu/store/…/include/unicode/unistr.h
libunistring@1.0    /gnu/store/…/include/unistr.h

You may also specify glob patterns with wildcards. For example, here is how you would search for packages providing .service files:

$ guix locate -g '*.service'
man-db@2.11.1        …/lib/systemd/system/man-db.service
wpa-supplicant@2.10  …/system-services/fi.w1.wpa_supplicant1.service

The guix locate command relies on a database that maps file names to package names. By default, it automatically creates that database if it does not exist yet by traversing packages available locally, which can take a few minutes (depending on the size of your store and the speed of your storage device).

Note: For now, guix locate builds its database based on purely local knowledge—meaning that you will not find packages that never reached your store. Eventually it will support downloading a pre-built database so you can potentially find more packages.

By default, guix locate first tries to look for a system-wide database, usually under /var/cache/guix/locate; if it does not exist or is too old, it falls back to the per-user database, by default under ~/.cache/guix/locate. On a multi-user system, administrators may want to periodically update the system-wide database so that all users can benefit from it, for instance by setting up package-database-service-type (see package-database-service-type).

The general syntax is:

guix locate [options…] file…

... where file is the name of a file to search for (specifically, the “base name” of the file: files whose parent directories are called file are not matched).

The available options are as follows:

--glob

-g

Interpret file… as glob patterns—patterns that may include wildcards, such as ‘*.scm’ to denote all files ending in ‘.scm’.

--stats

Display database statistics.

--update

-u

Update the file database.

By default, the database is automatically updated when it is too old.

--clear

Clear the database and re-populate it.

This option lets you start anew, ensuring old data is removed from the database, which also avoids having an endlessly growing database. By default guix locate automatically does that periodically, though infrequently.

--database=file

Use file as the database, creating it if necessary.

By default, guix locate picks the database under ~/.cache/guix or /var/cache/guix, whichever is the most recent one.

--method=method

-m method

Use method to select the set of packages to index. Possible values are:

manifests

This is the default method: it works by traversing profiles on the machine and recording packages it encounters—packages you or other users of the machine installed, directly or indirectly. It is fast but it can miss other packages available in the store but not referred to by any profile.

store

This is a slower but more exhaustive method: it checks among all the existing packages those that are available in the store and records them.

5.6 Invoking guix gc

Packages that are installed, but not used, may be garbage-collected. The guix gc command allows users to explicitly run the garbage collector to reclaim space from the /gnu/store directory. It is the only way to remove files from /gnu/store—removing files or directories manually may break it beyond repair!

The garbage collector has a set of known roots: any file under /gnu/store reachable from a root is considered live and cannot be deleted; any other file is considered dead and may be deleted. The set of garbage collector roots (“GC roots” for short) includes default user profiles; by default, the symlinks under /var/guix/gcroots represent these GC roots. New GC roots can be added with guix build --root, for example (see Invoking guix build). The guix gc --list-roots command lists them.

Prior to running guix gc --collect-garbage to make space, it is often useful to remove old generations from user profiles; that way, old package builds referenced by those generations can be reclaimed. This is achieved by running guix package --delete-generations (see Invoking guix package).

Our recommendation is to run a garbage collection periodically, or when you are short on disk space. For instance, to guarantee that at least 5 GB are available on your disk, simply run:

guix gc -F 5G

It is perfectly safe to run as a non-interactive periodic job (see Scheduled Job Execution, for how to set up such a job). Running guix gc with no arguments will collect as much garbage as it can, but that is often inconvenient: you may find yourself having to rebuild or re-download software that is “dead” from the GC viewpoint but that is necessary to build other pieces of software—e.g., the compiler tool chain.

The guix gc command has three modes of operation: it can be used to garbage-collect any dead files (the default), to delete specific files (the --delete option), to print garbage-collector information, or for more advanced queries. The garbage collection options are as follows:

--collect-garbage[=min]

-C [min]

Collect garbage—i.e., unreachable /gnu/store files and sub-directories. This is the default operation when no option is specified.

When min is given, stop once min bytes have been collected. min may be a number of bytes, or it may include a unit as a suffix, such as MiB for mebibytes and GB for gigabytes (see size specifications in GNU Coreutils).

When min is omitted, collect all the garbage.

--free-space=free

-F free

Collect garbage until free space is available under /gnu/store, if possible; free denotes storage space, such as 500MiB, as described above.

When free or more is already available in /gnu/store, do nothing and exit immediately.

--delete-generations[=duration]

-d [duration]

Before starting the garbage collection process, delete all the generations older than duration, for all the user profiles and home environment generations; when run as root, this applies to all the profiles of all the users.

For example, this command deletes all the generations of all your profiles that are older than 2 months (except generations that are current), and then proceeds to free space until at least 10 GiB are available:

guix gc -d 2m -F 10G

--delete

-D

Attempt to delete all the store files and directories specified as arguments. This fails if some of the files are not in the store, or if they are still live.

--list-failures

List store items corresponding to cached build failures.

This prints nothing unless the daemon was started with --cache-failures (see --cache-failures).

--list-roots

List the GC roots owned by the user; when run as root, list all the GC roots.

--list-busy

List store items in use by currently running processes. These store items are effectively considered GC roots: they cannot be deleted.

--clear-failures

Remove the specified store items from the failed-build cache.

Again, this option only makes sense when the daemon is started with --cache-failures. Otherwise, it does nothing.

--list-dead

Show the list of dead files and directories still present in the store—i.e., files and directories no longer reachable from any root.

--list-live

Show the list of live store files and directories.

In addition, the references among existing store files can be queried:

--references ¶

--referrers

List the references (respectively, the referrers) of store files given as arguments.

--requisites ¶

-R

List the requisites of the store files passed as arguments. Requisites include the store files themselves, their references, and the references of these, recursively. In other words, the returned list is the transitive closure of the store files.

See Invoking guix size, for a tool to profile the size of the closure of an element. See Invoking guix graph, for a tool to visualize the graph of references.

--derivers ¶

Return the derivation(s) leading to the given store items (see Derivations).

For example, this command:

guix gc --derivers $(guix package -I ^emacs$ | cut -f4)

returns the .drv file(s) leading to the emacs package installed in your profile.

Note that there may be zero matching .drv files, for instance because these files have been garbage-collected. There can also be more than one matching .drv due to fixed-output derivations.

Lastly, the following options allow you to check the integrity of the store and to control disk usage.

--verify[=options] ¶

Verify the integrity of the store.

By default, make sure that all the store items marked as valid in the database of the daemon actually exist in /gnu/store.

When provided, options must be a comma-separated list containing one or more of contents and repair.

When passing --verify=contents, the daemon computes the content hash of each store item and compares it against its hash in the database. Hash mismatches are reported as data corruptions. Because it traverses all the files in the store, this command can take a long time, especially on systems with a slow disk drive.

Using --verify=repair or --verify=contents,repair causes the daemon to try to repair corrupt store items by fetching substitutes for them (see Substitutes). Because repairing is not atomic, and thus potentially dangerous, it is available only to the system administrator. A lightweight alternative, when you know exactly which items in the store are corrupt, is guix build --repair (see Invoking guix build).

--optimize ¶

Optimize the store by hard-linking identical files—this is deduplication.

The daemon performs deduplication after each successful build or archive import, unless it was started with --disable-deduplication (see --disable-deduplication). Thus, this option is primarily useful when the daemon was running with --disable-deduplication.

--vacuum-database ¶

Guix uses an sqlite database to keep track of the items in the store (see The Store). Over time it is possible that the database may grow to a large size and become fragmented. As a result, one may wish to clear the freed space and join the partially used pages in the database left behind from removed packages or after running the garbage collector. Running sudo guix gc --vacuum-database will lock the database and VACUUM the store, defragmenting the database and purging freed pages, unlocking the database when it finishes.

5.7 Invoking guix pull

Packages are installed or upgraded to the latest version available in the distribution currently available on your local machine. To update that distribution, along with the Guix tools, you must run guix pull: the command downloads the latest Guix source code and package descriptions, and deploys it. Source code is downloaded from a Git repository, by default the official GNU Guix repository, though this can be customized. guix pull ensures that the code it downloads is authentic by verifying that commits are signed by Guix developers.

Specifically, guix pull downloads code from the channels (see Channels) specified by one of the following, in this order:

1. the --channels option;
2. the user’s ~/.config/guix/channels.scm file, unless -q is passed;
3. the system-wide /etc/guix/channels.scm file, unless -q is passed (on Guix System, this file can be declared in the operating system configuration, see channels field of guix-configuration);
4. the built-in default channels specified in the %default-channels variable.

On completion, guix package will use packages and package versions from this just-retrieved copy of Guix. Not only that, but all the Guix commands and Scheme modules will also be taken from that latest version. New guix sub-commands added by the update also become available.

Any user can update their Guix copy using guix pull, and the effect is limited to the user who ran guix pull. For instance, when user root runs guix pull, this has no effect on the version of Guix that user alice sees, and vice versa.

The result of running guix pull is a profile available under ~/.config/guix/current containing the latest Guix.

The --list-generations or -l option lists past generations produced by guix pull, along with details about their provenance:

$ guix pull -l
Generation 1	Jun 10 2018 00:18:18
  guix 65956ad
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Generation 2	Jun 11 2018 11:02:49
  guix e0cc7f6
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d

Generation 3	Jun 13 2018 23:31:07	(current)
  guix 844cc1c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: 844cc1c8f394f03b404c5bb3aee086922373490c

See guix describe, for other ways to describe the current status of Guix.

This ~/.config/guix/current profile works exactly like the profiles created by guix package (see Invoking guix package). That is, you can list generations, roll back to the previous generation—i.e., the previous Guix—and so on:

$ guix pull --roll-back
switched from generation 3 to 2
$ guix pull --delete-generations=1
deleting /var/guix/profiles/per-user/charlie/current-guix-1-link

You can also use guix package (see Invoking guix package) to manage the profile by naming it explicitly:

$ guix package -p ~/.config/guix/current --roll-back
switched from generation 3 to 2
$ guix package -p ~/.config/guix/current --delete-generations=1
deleting /var/guix/profiles/per-user/charlie/current-guix-1-link

The guix pull command is usually invoked with no arguments, but it supports the following options:

--url=url

--commit=commit

--branch=branch

Download code for the guix channel from the specified url, at the given commit (a valid Git commit ID represented as a hexadecimal string or the name of a tag), or branch.

These options are provided for convenience, but you can also specify your configuration in the ~/.config/guix/channels.scm file or using the --channels option (see below).

--channels=file

-C file

Read the list of channels from file instead of ~/.config/guix/channels.scm or /etc/guix/channels.scm. file must contain Scheme code that evaluates to a list of channel objects. See Channels, for more information.

--no-channel-files

-q

Inhibit loading of the user and system channel files, ~/.config/guix/channels.scm and /etc/guix/channels.scm.

--news

-N

Display news written by channel authors for their users for changes made since the previous generation (see Writing Channel News). When --details is passed, additionally display new and upgraded packages.

You can view that information for previous generations with guix pull -l.

--list-generations[=pattern]

-l [pattern]

List all the generations of ~/.config/guix/current or, if pattern is provided, the subset of generations that match pattern. The syntax of pattern is the same as with guix package --list-generations (see Invoking guix package).

By default, this prints information about the channels used in each revision as well as the corresponding news entries. If you pass --details, it will also print the list of packages added and upgraded in each generation compared to the previous one.

--details

Instruct --list-generations or --news to display more information about the differences between subsequent generations—see above.

--roll-back ¶

Roll back to the previous generation of ~/.config/guix/current—i.e., undo the last transaction.

--switch-generation=pattern ¶

-S pattern

Switch to a particular generation defined by pattern.

pattern may be either a generation number or a number prefixed with “+” or “-”. The latter means: move forward/backward by a specified number of generations. For example, if you want to return to the latest generation after --roll-back, use --switch-generation=+1.

--delete-generations[=pattern]

-d [pattern]

When pattern is omitted, delete all generations except the current one.

This command accepts the same patterns as --list-generations. When pattern is specified, delete the matching generations. When pattern specifies a duration, generations older than the specified duration match. For instance, --delete-generations=1m deletes generations that are more than one month old.

If the current generation matches, it is not deleted.

Note that deleting generations prevents rolling back to them. Consequently, this command must be used with care.

See Invoking guix describe, for a way to display information about the current generation only.

--profile=profile

-p profile

Use profile instead of ~/.config/guix/current.

--dry-run

-n

Show which channel commit(s) would be used and what would be built or substituted but do not actually do it.

--allow-downgrades

Allow pulling older or unrelated revisions of channels than those currently in use.

By default, guix pull protects against so-called “downgrade attacks” whereby the Git repository of a channel would be reset to an earlier or unrelated revision of itself, potentially leading you to install older, known-vulnerable versions of software packages.

Note: Make sure you understand its security implications before using --allow-downgrades.

--disable-authentication

Allow pulling channel code without authenticating it.

By default, guix pull authenticates code downloaded from channels by verifying that its commits are signed by authorized developers, and raises an error if this is not the case. This option instructs it to not perform any such verification.

Note: Make sure you understand its security implications before using --disable-authentication.

--system=system

-s system

Attempt to build for system—e.g., i686-linux—instead of the system type of the build host.

--bootstrap

Use the bootstrap Guile to build the latest Guix. This option is only useful to Guix developers.

The channel mechanism allows you to instruct guix pull which repository and branch to pull from, as well as additional repositories containing package modules that should be deployed. See Channels, for more information.

In addition, guix pull supports all the common build options (see Common Build Options).

5.8 Invoking guix time-machine

The guix time-machine command provides access to other revisions of Guix, for example to install older versions of packages, or to reproduce a computation in an identical environment. The revision of Guix to be used is defined by a commit or by a channel description file created by guix describe (see Invoking guix describe).

Let’s assume that you want to travel to those days of November 2020 when version 1.2.0 of Guix was released and, once you’re there, run the guile of that time:

guix time-machine --commit=v1.2.0 -- \
  environment -C --ad-hoc guile -- guile

The command above fetches Guix 1.2.0 (and possibly other channels specified by your channels.scm configuration files—see below) and runs its guix environment command to spawn an environment in a container running guile (guix environment has since been subsumed by guix shell; see Invoking guix shell). It’s like driving a DeLorean¹²! The first guix time-machine invocation can be expensive: it may have to download or even build a large number of packages; the result is cached though and subsequent commands targeting the same commit are almost instantaneous.

As for guix pull, in the absence of any options, time-machine fetches the latest commits of the channels specified in ~/.config/guix/channels.scm, /etc/guix/channels.scm, or the default channels; the -q option lets you ignore these configuration files. The command:

guix time-machine -q -- build hello

will thus build the package hello as defined in the main branch of Guix, without any additional channel, which is in general a newer revision of Guix than you have installed. Time travel works in both directions!

Note: The history of Guix is immutable and guix time-machine provides the exact same software as they are in a specific Guix revision. Naturally, no security fixes are provided for old versions of Guix or its channels. A careless use of guix time-machine opens the door to security vulnerabilities. See --allow-downgrades.

guix time-machine raises an error when attempting to travel to commits older than “v0.16.0” (commit ‘4a0b87f0’), dated Dec. 2018. This is one of the oldest commits supporting the channel mechanism that makes “time travel” possible.

Note: Although it should technically be possible to travel to such an old commit, the ease to do so will largely depend on the availability of binary substitutes. When traveling to a distant past, some packages may not easily build from source anymore. One such example are old versions of OpenSSL whose tests would fail after a certain date. This particular problem can be worked around by running a virtual build machine with its clock set to the right time (see Virtual Build Machines).

The general syntax is:

guix time-machine options… -- command arg…

where command and arg… are passed unmodified to the guix command of the specified revision. The options that define this revision are the same as for guix pull (see Invoking guix pull):

--url=url

--commit=commit

--branch=branch

Use the guix channel from the specified url, at the given commit (a valid Git commit ID represented as a hexadecimal string or the name of a tag), or branch.

--channels=file

-C file

Read the list of channels from file. file must contain Scheme code that evaluates to a list of channel objects. See Channels for more information.

--no-channel-files

-q

Inhibit loading of the user and system channel files, ~/.config/guix/channels.scm and /etc/guix/channels.scm.

Thus, guix time-machine -q is equivalent to the following Bash command, using the “process substitution” syntax (see Process Substitution in The GNU Bash Reference Manual):

guix time-machine -C <(echo %default-channels) …

Note that guix time-machine can trigger builds of channels and their dependencies, and these are controlled by the standard build options (see Common Build Options).

If guix time-machine is executed without any command, it prints the file name of the profile that would be used to execute the command. This is sometimes useful if you need to get store file name of the profile—e.g., when you want to guix copy it.

5.9 Inferiors

Note: The functionality described here is a “technology preview” as of version 84df0c4. As such, the interface is subject to change.

Sometimes you might need to mix packages from the revision of Guix you’re currently running with packages available in a different revision of Guix. Guix inferiors allow you to achieve that by composing different Guix revisions in arbitrary ways.

Technically, an “inferior” is essentially a separate Guix process connected to your main Guix process through a REPL (see Invoking guix repl). The (guix inferior) module allows you to create inferiors and to communicate with them. It also provides a high-level interface to browse and manipulate the packages that an inferior provides—inferior packages.

When combined with channels (see Channels), inferiors provide a simple way to interact with a separate revision of Guix. For example, let’s assume you want to install in your profile the current guile package, along with the guile-json as it existed in an older revision of Guix—perhaps because the newer guile-json has an incompatible API and you want to run your code against the old API. To do that, you could write a manifest for use by guix package --manifest (see Writing Manifests); in that manifest, you would create an inferior for that old Guix revision you care about, and you would look up the guile-json package in the inferior:

(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;for 'first'

(define channels
  ;; This is the old revision from which we want to
  ;; extract guile-json.
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; An inferior representing the above revision.
  (inferior-for-channels channels))

;; Now create a manifest with the current "guile" package
;; and the old "guile-json" package.
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

On its first run, guix package --manifest might have to build the channel you specified before it can create the inferior; subsequent runs will be much faster because the Guix revision will be cached.

The (guix inferior) module provides the following procedures to open an inferior:

Procedure: inferior-for-channels channels [#:cache-directory] [#:ttl]

Return an inferior for channels, a list of channels. Use the cache at cache-directory, where entries can be reclaimed after ttl seconds. This procedure opens a new connection to the build daemon.

As a side effect, this procedure may build or substitute binaries for channels, which can take time.

Procedure: open-inferior directory [#:command "bin/guix"]

Open the inferior Guix in directory, running directory/command repl or equivalent. Return #f if the inferior could not be launched.

The procedures listed below allow you to obtain and manipulate inferior packages.

Procedure: inferior-packages inferior

Return the list of packages known to inferior.

Procedure: lookup-inferior-packages inferior name [version]

Return the sorted list of inferior packages matching name in inferior, with highest version numbers first. If version is true, return only packages with a version number prefixed by version.

Procedure: inferior-package? obj

Return true if obj is an inferior package.

Procedure: inferior-package-name package

Procedure: inferior-package-version package

Procedure: inferior-package-synopsis package

Procedure: inferior-package-description package

Procedure: inferior-package-home-page package

Procedure: inferior-package-location package

Procedure: inferior-package-inputs package

Procedure: inferior-package-native-inputs package

Procedure: inferior-package-propagated-inputs package

Procedure: inferior-package-transitive-propagated-inputs package

Procedure: inferior-package-native-search-paths package

Procedure: inferior-package-transitive-native-search-paths package

Procedure: inferior-package-search-paths package

These procedures are the counterpart of package record accessors (see package Reference). Most of them work by querying the inferior package comes from, so the inferior must still be live when you call these procedures.

Inferior packages can be used transparently like any other package or file-like object in G-expressions (see G-Expressions). They are also transparently handled by the packages->manifest procedure, which is commonly used in manifests (see the --manifest option of guix package). Thus you can insert an inferior package pretty much anywhere you would insert a regular package: in manifests, in the packages field of your operating-system declaration, and so on.

5.10 Invoking guix describe

Often you may want to answer questions like: “Which revision of Guix am I using?” or “Which channels am I using?” This is useful information in many situations: if you want to replicate an environment on a different machine or user account, if you want to report a bug or to determine what change in the channels you are using caused it, or if you want to record your system state for reproducibility purposes. The guix describe command answers these questions.

When run from a guix pulled guix, guix describe displays the channel(s) that it was built from, including their repository URL and commit IDs (see Channels):

$ guix describe
Generation 10	Sep 03 2018 17:32:44	(current)
  guix e0fa68c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e0fa68c7718fffd33d81af415279d6ddb518f727

If you’re familiar with the Git version control system, this is similar in spirit to git describe; the output is also similar to that of guix pull --list-generations, but limited to the current generation (see the --list-generations option). Because the Git commit ID shown above unambiguously refers to a snapshot of Guix, this information is all it takes to describe the revision of Guix you’re using, and also to replicate it.

To make it easier to replicate Guix, guix describe can also be asked to return a list of channels instead of the human-readable description above:

$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (commit
          "e0fa68c7718fffd33d81af415279d6ddb518f727")
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
              "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

You can save this to a file and feed it to guix pull -C on some other machine or at a later point in time, which will instantiate this exact Guix revision (see the -C option). From there on, since you’re able to deploy the same revision of Guix, you can just as well replicate a complete software environment. We humbly think that this is awesome, and we hope you’ll like it too!

The details of the options supported by guix describe are as follows:

--format=format

-f format

Produce output in the specified format, one of:

human

produce human-readable output;

channels

produce a list of channel specifications that can be passed to guix pull -C or installed as ~/.config/guix/channels.scm (see Invoking guix pull);

channels-sans-intro

like channels, but omit the introduction field; use it to produce a channel specification suitable for Guix version 1.1.0 or earlier—the introduction field has to do with channel authentication (see Channel Authentication) and is not supported by these older versions;

json ¶

produce a list of channel specifications in JSON format;

recutils

produce a list of channel specifications in Recutils format.

--list-formats

Display available formats for --format option.

--profile=profile

-p profile

Display information about profile.

5.11 Invoking guix archive

The guix archive command allows users to export files from the store into a single archive, and to later import them on a machine that runs Guix. In particular, it allows store files to be transferred from one machine to the store on another machine.

Note: If you’re looking for a way to produce archives in a format suitable for tools other than Guix, see Invoking guix pack.

To export store files as an archive to standard output, run:

guix archive --export options specifications...

specifications may be either store file names or package specifications, as for guix package (see Invoking guix package). For instance, the following command creates an archive containing the gui output of the git package and the main output of emacs:

guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar

If the specified packages are not built yet, guix archive automatically builds them. The build process may be controlled with the common build options (see Common Build Options).

To transfer the emacs package to a machine connected over SSH, one would run:

guix archive --export -r emacs | ssh the-machine guix archive --import

Similarly, a complete user profile may be transferred from one machine to another like this:

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh the-machine guix archive --import

However, note that, in both examples, all of emacs and the profile as well as all of their dependencies are transferred (due to -r), regardless of what is already available in the store on the target machine. The --missing option can help figure out which items are missing from the target store. The guix copy command simplifies and optimizes this whole process, so this is probably what you should use in this case (see Invoking guix copy).

Each store item is written in the normalized archive or nar format (described below), and the output of guix archive --export (and input of guix archive --import) is a nar bundle.

The nar format is comparable in spirit to ‘tar’, but with differences that make it more appropriate for our purposes. First, rather than recording all Unix metadata for each file, the nar format only mentions the file type (regular, directory, or symbolic link); Unix permissions and owner/group are dismissed. Second, the order in which directory entries are stored always follows the order of file names according to the C locale collation order. This makes archive production fully deterministic.

That nar bundle format is essentially the concatenation of zero or more nars along with metadata for each store item it contains: its file name, references, corresponding derivation, and a digital signature.

When exporting, the daemon digitally signs the contents of the archive, and that digital signature is appended. When importing, the daemon verifies the signature and rejects the import in case of an invalid signature or if the signing key is not authorized.

The main options are:

--export

Export the specified store files or packages (see below). Write the resulting archive to the standard output.

Dependencies are not included in the output, unless --recursive is passed.

-r

--recursive

When combined with --export, this instructs guix archive to include dependencies of the given items in the archive. Thus, the resulting archive is self-contained: it contains the closure of the exported store items.

--import

Read an archive from the standard input, and import the files listed therein into the store. Abort if the archive has an invalid digital signature, or if it is signed by a public key not among the authorized keys (see --authorize below).

--missing

Read a list of store file names from the standard input, one per line, and write on the standard output the subset of these files missing from the store.

--generate-key[=parameters] ¶

Generate a new key pair for the daemon. This is a prerequisite before archives can be exported with --export. This operation is usually instantaneous but it can take time if the system’s entropy pool needs to be refilled. On Guix System, guix-service-type takes care of generating this key pair the first boot.

The generated key pair is typically stored under /etc/guix, in signing-key.pub (public key) and signing-key.sec (private key, which must be kept secret). When parameters is omitted, an ECDSA key using the Ed25519 curve is generated, or, for Libgcrypt versions before 1.6.0, it is a 4096-bit RSA key. Alternatively, parameters can specify genkey parameters suitable for Libgcrypt (see gcry_pk_genkey in The Libgcrypt Reference Manual).

--authorize ¶

Authorize imports signed by the public key passed on standard input. The public key must be in “s-expression advanced format”—i.e., the same format as the signing-key.pub file.

The list of authorized keys is kept in the human-editable file /etc/guix/acl. The file contains “advanced-format s-expressions” and is structured as an access-control list in the Simple Public-Key Infrastructure (SPKI).

--extract=directory

-x directory

Read a single-item archive as served by substitute servers (see Substitutes) and extract it to directory. This is a low-level operation needed in only very narrow use cases; see below.

For example, the following command extracts the substitute for Emacs served by bordeaux.guix.gnu.org to /tmp/emacs:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/gzip/…-emacs-24.5 \
  | gunzip | guix archive -x /tmp/emacs

Single-item archives are different from multiple-item archives produced by guix archive --export; they contain a single store item, and they do not embed a signature. Thus this operation does no signature verification and its output should be considered unsafe.

The primary purpose of this operation is to facilitate inspection of archive contents coming from possibly untrusted substitute servers (see Invoking guix challenge).

--list

-t

Read a single-item archive as served by substitute servers (see Substitutes) and print the list of files it contains, as in this example:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

6.1 Specifying Additional Channels

You can specify additional channels to pull from. To use a channel, write ~/.config/guix/channels.scm to instruct guix pull to pull from it in addition to the default Guix channel(s):

;; Add variant packages to those Guix provides.
(cons (channel
        (name 'variant-packages)
        (url "https://example.org/variant-packages.git"))
      %default-channels)

Note that the snippet above is (as always!) Scheme code; we use cons to add a channel the list of channels that the variable %default-channels is bound to (see cons and lists in GNU Guile Reference Manual). With this file in place, guix pull builds not only Guix but also the package modules from your own repository. The result in ~/.config/guix/current is the union of Guix with your own package modules:

$ guix describe
Generation 19	Aug 27 2018 16:20:48
  guix d894ab8
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  variant-packages dd3df5e
    repository URL: https://example.org/variant-packages.git
    branch: master
    commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb

The output of guix describe above shows that we’re now running Generation 19 and that it includes both Guix and packages from the variant-packages channel (see Invoking guix describe).

6.2 Using a Custom Guix Channel

The channel called guix specifies where Guix itself—its command-line tools as well as its package collection—should be downloaded. For instance, suppose you want to update from another copy of the Guix repository at example.org, and specifically the super-hacks branch, you can write in ~/.config/guix/channels.scm this specification:

;; Tell 'guix pull' to use another repo.
(list (channel
        (name 'guix)
        (url "https://example.org/another-guix.git")
        (branch "super-hacks")))

From there on, guix pull will fetch code from the super-hacks branch of the repository at example.org. The authentication concern is addressed below (see Channel Authentication).

Note that you can specify a local directory on the url field above if the channel that you intend to use resides on a local file system. However, in this case guix checks said directory for ownership before any further processing. This means that if the user is not the directory owner, but wants to use it as their default, they will then need to set it as a safe directory in their global git configuration file. Otherwise, guix will refuse to even read it. Supposing your system-wide local directory is at /src/guix.git, you would then create a git configuration file at ~/.gitconfig with the following contents:

[safe]
        directory = /src/guix.git

This also applies to the root user unless when called with sudo by the directory owner.

6.3 Replicating Guix

The guix describe command shows precisely which commits were used to build the instance of Guix we’re using (see Invoking guix describe). We can replicate this instance on another machine or at a different point in time by providing a channel specification “pinned” to these commits that looks like this:

;; Deploy specific commits of my channels of interest.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "6298c3ffd9654d3231a6f25390b056483e8f407c"))
      (channel
       (name 'variant-packages)
       (url "https://example.org/variant-packages.git")
       (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

To obtain this pinned channel specification, the easiest way is to run guix describe and to save its output in the channels format in a file, like so:

guix describe -f channels > channels.scm

The resulting channels.scm file can be passed to the -C option of guix pull (see Invoking guix pull) or guix time-machine (see Invoking guix time-machine), as in this example:

guix time-machine -C channels.scm -- shell python -- python3

Given the channels.scm file, the command above will always fetch the exact same Guix instance, then use that instance to run the exact same Python (see Invoking guix shell). On any machine, at any time, it ends up running the exact same binaries, bit for bit.

Pinned channels address a problem similar to “lock files” as implemented by some deployment tools—they let you pin and reproduce a set of packages. In the case of Guix though, you are effectively pinning the entire package set as defined at the given channel commits; in fact, you are pinning all of Guix, including its core modules and command-line tools. You’re also getting strong guarantees that you are, indeed, obtaining the exact same software.

This gives you super powers, allowing you to track the provenance of binary artifacts with very fine grain, and to reproduce software environments at will—some sort of “meta reproducibility” capabilities, if you will. See Inferiors, for another way to take advantage of these super powers.

6.4 Customizing the System-Wide Guix

If you’re running Guix System or building system images with it, maybe you will want to customize the system-wide guix it provides—specifically, /run/current-system/profile/bin/guix. For example, you might want to provide additional channels or to pin its revision.

This can be done using the guix-for-channels procedure, which returns a package for the given channels, and using it as part of your operating system configuration, as in this example:

(use-modules (gnu packages package-management)
             (guix channels))

(define my-channels
  ;; Channels that should be available to
  ;; /run/current-system/profile/bin/guix.
  (append
   (list (channel
          (name 'guix-science)
          (url "https://github.com/guix-science/guix-science")
          (branch "master")))
   %default-channels))

(operating-system
  ;; …
  (services
    ;; Change the package used by 'guix-service-type'.
    (modify-services %base-services
      (guix-service-type
       config => (guix-configuration
                  (inherit config)
                  (channels my-channels)
                  (guix (guix-for-channels my-channels)))))))

The resulting operating system will have both the guix and the guix-science channels visible by default. The channels field of guix-configuration above further ensures that /etc/guix/channels.scm, which is used by guix pull, specifies the same set of channels (see channels field of guix-configuration).

The (gnu packages package-management) module exports the guix-for-channels procedure, described below.

Procedure: guix-for-channels channels

Return a package corresponding to channels.

The result is a “regular” package, which can be used in guix-configuration as shown above or in any other place that expects a package.

6.5 Channel Authentication

The guix pull and guix time-machine commands authenticate the code retrieved from channels: they make sure each commit that is fetched is signed by an authorized developer. The goal is to protect from unauthorized modifications to the channel that would lead users to run malicious code.

As a user, you must provide a channel introduction in your channels file so that Guix knows how to authenticate its first commit. A channel specification, including its introduction, looks something along these lines:

(channel
  (name 'some-channel)
  (url "https://example.org/some-channel.git")
  (introduction
   (make-channel-introduction
    "6f0d8cc0d88abb59c324b2990bfee2876016bb86"
    (openpgp-fingerprint
     "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))

The specification above shows the name and URL of the channel. The call to make-channel-introduction above specifies that authentication of this channel starts at commit 6f0d8cc…, which is signed by the OpenPGP key with fingerprint CABB A931….

For the main channel, called guix, you automatically get that information from your Guix installation. For other channels, include the channel introduction provided by the channel authors in your channels.scm file. Make sure you retrieve the channel introduction from a trusted source since that is the root of your trust.

If you’re curious about the authentication mechanics, read on!

6.6 Channels with Substitutes

When running guix pull, Guix will first compile the definitions of every available package. This is an expensive operation for which substitutes (see Substitutes) may be available. The following snippet in channels.scm will ensure that guix pull uses the latest commit with available substitutes for the package definitions: this is done by querying the continuous integration server at https://ci.guix.gnu.org.

(use-modules (guix ci))

(list (channel-with-substitutes-available
       %default-guix-channel
       "https://ci.guix.gnu.org"))

Note that this does not mean that all the packages that you will install after running guix pull will have available substitutes. It only ensures that guix pull will not try to compile package definitions. This is particularly useful when using machines with limited resources.

6.7 Creating a Channel

Let’s say you have a bunch of custom package variants or personal packages that you think would make little sense to contribute to the Guix project, but would like to have these packages transparently available to you at the command line. By creating a channel, you can use and publish such a package collection. This involves the following steps:

1. A channel lives in a Git repository so the first step, when creating a channel, is to create its repository:

   mkdir my-channel
   cd my-channel
   git init
   

2. The next step is to create files containing package modules (see Package Modules), each of which will contain one or more package definitions (see Defining Packages). A channel can provide things other than packages, such as build systems or services; we’re using packages as it’s the most common use case.

   For example, Alice might want to provide a module called (alice packages greetings) that will provide her favorite “hello world” implementations. To do that Alice will create a directory corresponding to that module name.

   mkdir -p alice/packages
   $EDITOR alice/packages/greetings.scm
   git add alice/packages/greetings.scm
   

   You can name your package modules however you like; the main constraint to keep in mind is to avoid name clashes with other package collections, which is why our hypothetical Alice wisely chose the (alice packages …) name space.

   Note that you can also place modules in a sub-directory of the repository; see Package Modules in a Sub-directory, for more info on that.

3. With this first module in place, the next step is to test the packages it provides. This can be done with guix build, which needs to be told to look for modules in the Git checkout. For example, assuming (alice packages greetings) provides a package called hi-from-alice, Alice will run this command from the Git checkout:

   guix build -L. hi-from-alice
   

   ... where -L. adds the current directory to Guile’s load path (see Load Paths in GNU Guile Reference Manual).

4. It might take Alice a few iterations to obtain satisfying package definitions. Eventually Alice will commit this file:

   git commit
   

   As a channel author, consider bundling authentication material with your channel so that users can authenticate it. See Channel Authentication, and Specifying Channel Authorizations, for info on how to do it.

5. To use Alice’s channel, anyone can now add it to their channel file (see Specifying Additional Channels) and run guix pull (see Invoking guix pull):

   $EDITOR ~/.config/guix/channels.scm
   guix pull
   

   Guix will now behave as if the root directory of that channel’s Git repository had been permanently added to the Guile load path. In this example, (alice packages greetings) will automatically be found by the guix command.

Voilà!

Warning: Before you publish your channel, we would like to share a few words of caution:

• Before publishing a channel, please consider contributing your package definitions to Guix proper (see Contributing). Guix as a project is open to free software of all sorts, and packages in Guix proper are readily available to all Guix users and benefit from the project’s quality assurance process.
• Package modules and package definitions are Scheme code that uses various programming interfaces (APIs). We, Guix developers, never change APIs gratuitously, but we do not commit to freezing APIs either. When you maintain package definitions outside Guix, we consider that the compatibility burden is on you.
• Corollary: if you’re using an external channel and that channel breaks, please report the issue to the channel authors, not to the Guix project.

You’ve been warned! Having said this, we believe external channels are a practical way to exert your freedom to augment Guix’ package collection and to share your improvements, which are basic tenets of free software. Please email us at guix-devel@gnu.org if you’d like to discuss this.

6.8 Package Modules in a Sub-directory

As a channel author, you may want to keep your channel modules in a sub-directory. If your modules are in the sub-directory guix, you must add a meta-data file .guix-channel that contains:

(channel
  (version 0)
  (directory "guix"))

The modules must be underneath the specified directory, as the directory changes Guile’s load-path. For example, if .guix-channel has (directory "base"), then a module defined as (define-module (gnu packages fun)) must be located at base/gnu/packages/fun.scm.

Doing this allows for only parts of a repository to be used as a channel, as Guix expects valid Guile modules when pulling. For instance, guix deploy machine configuration files are not valid Guile modules, and treating them as such would make guix pull fail.

6.9 Declaring Channel Dependencies

Channel authors may decide to augment a package collection provided by other channels. They can declare their channel to be dependent on other channels in a meta-data file .guix-channel, which is to be placed in the root of the channel repository.

The meta-data file should contain a simple S-expression like this:

(channel
 (version 0)
 (dependencies
  (channel
   (name some-collection)
   (url "https://example.org/first-collection.git")

   ;; The 'introduction' bit below is optional: you would
   ;; provide it for dependencies that can be authenticated.
   (introduction
    (channel-introduction
      (version 0)
      (commit "a8883b58dc82e167c96506cf05095f37c2c2c6cd")
      (signer "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))
  (channel
   (name some-other-collection)
   (url "https://example.org/second-collection.git")
   (branch "testing"))))

In the above example this channel is declared to depend on two other channels, which will both be fetched automatically. The modules provided by the channel will be compiled in an environment where the modules of all these declared channels are available.

For the sake of reliability and maintainability, you should avoid dependencies on channels that you don’t control, and you should aim to keep the number of dependencies to a minimum.

6.10 Specifying Channel Authorizations

As we saw above, Guix ensures the source code it pulls from channels comes from authorized developers. As a channel author, you need to specify the list of authorized developers in the .guix-authorizations file in the channel’s Git repository. The authentication rule is simple: each commit must be signed by a key listed in the .guix-authorizations file of its parent commit(s)¹³ The .guix-authorizations file looks like this:

;; Example '.guix-authorizations' file.

(authorizations
 (version 0)               ;current file format version

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alice"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "bob"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "charlie"))))

Each fingerprint is followed by optional key/value pairs, as in the example above. Currently these key/value pairs are ignored.

This authentication rule creates a chicken-and-egg issue: how do we authenticate the first commit? Related to that: how do we deal with channels whose repository history contains unsigned commits and lack .guix-authorizations? And how do we fork existing channels?

Channel introductions answer these questions by describing the first commit of a channel that should be authenticated. The first time a channel is fetched with guix pull or guix time-machine, the command looks up the introductory commit and verifies that it is signed by the specified OpenPGP key. From then on, it authenticates commits according to the rule above. Authentication fails if the target commit is neither a descendant nor an ancestor of the introductory commit.

Additionally, your channel must provide all the OpenPGP keys that were ever mentioned in .guix-authorizations, stored as .key files, which can be either binary or “ASCII-armored”. By default, those .key files are searched for in the branch named keyring but you can specify a different branch name in .guix-channel like so:

(channel
  (version 0)
  (keyring-reference "my-keyring-branch"))

To summarize, as the author of a channel, there are three things you have to do to allow users to authenticate your code:

1. Export the OpenPGP keys of past and present committers with gpg --export and store them in .key files, by default in a branch named keyring (we recommend making it an orphan branch).
2. Introduce an initial .guix-authorizations in the channel’s repository. Do that in a signed commit (see Commit Access, for information on how to sign Git commits).
3. Advertise the channel introduction, for instance on your channel’s web page. The channel introduction, as we saw above, is the commit/key pair—i.e., the commit that introduced .guix-authorizations, and the fingerprint of the OpenPGP used to sign it.

Before pushing to your public Git repository, you can run guix git authenticate to verify that you did sign all the commits you are about to push with an authorized key:

guix git authenticate commit signer

where commit and signer are your channel introduction. See Invoking guix git authenticate, for details.

Publishing a signed channel requires discipline: any mistake, such as an unsigned commit or a commit signed by an unauthorized key, will prevent users from pulling from your channel—well, that’s the whole point of authentication! Pay attention to merges in particular: merge commits are considered authentic if and only if they are signed by a key present in the .guix-authorizations file of both branches.

6.11 Primary URL

Channel authors can indicate the primary URL of their channel’s Git repository in the .guix-channel file, like so:

(channel
  (version 0)
  (url "https://example.org/guix.git"))

This allows guix pull to determine whether it is pulling code from a mirror of the channel; when that is the case, it warns the user that the mirror might be stale and displays the primary URL. That way, users cannot be tricked into fetching code from a stale mirror that does not receive security updates.

This feature only makes sense for authenticated repositories, such as the official guix channel, for which guix pull ensures the code it fetches is authentic.

6.12 Writing Channel News

Channel authors may occasionally want to communicate to their users information about important changes in the channel. You’d send them all an email, but that’s not convenient.

Instead, channels can provide a news file; when the channel users run guix pull, that news file is automatically read and guix pull --news can display the announcements that correspond to the new commits that have been pulled, if any.

To do that, channel authors must first declare the name of the news file in their .guix-channel file:

(channel
  (version 0)
  (news-file "etc/news.txt"))

The news file itself, etc/news.txt in this example, must look something like this:

(channel-news
  (version 0)
  (entry (tag "the-bug-fix")
         (title (en "Fixed terrible bug")
                (fr "Oh la la"))
         (body (en "@emph{Good news}!  It's fixed!")
               (eo "Certe ĝi pli bone funkcias nun!")))
  (entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
         (title (en "Added a great package")
                (ca "Què vol dir guix?"))
         (body (en "Don't miss the @code{hello} package!"))))

While the news file is using the Scheme syntax, avoid naming it with a .scm extension or else it will get picked up when building the channel and yield an error since it is not a valid module. Alternatively, you can move the channel module to a subdirectory and store the news file in another directory.

The file consists of a list of news entries. Each entry is associated with a commit or tag: it describes changes made in this commit, possibly in preceding commits as well. Users see entries only the first time they obtain the commit the entry refers to.

The title field should be a one-line summary while body can be arbitrarily long, and both can contain Texinfo markup (see Overview in GNU Texinfo). Both the title and body are a list of language tag/message tuples, which allows guix pull to display news in the language that corresponds to the user’s locale.

If you want to translate news using a gettext-based workflow, you can extract translatable strings with xgettext (see xgettext Invocation in GNU Gettext Utilities). For example, assuming you write news entries in English first, the command below creates a PO file containing the strings to translate:

xgettext -o news.po -l scheme -ken etc/news.txt

To sum up, yes, you could use your channel as a blog. But beware, this is not quite what your users might expect.

7.1 Invoking guix shell

The purpose of guix shell is to make it easy to create one-off software environments, without changing one’s profile. It is typically used to create development environments; it is also a convenient way to run applications without “polluting” your profile.

Note: The guix shell command was recently introduced to supersede guix environment (see Invoking guix environment). If you are familiar with guix environment, you will notice that it is similar but also—we hope!—more convenient.

The general syntax is:

guix shell [options] [package…]

Sometimes an interactive shell session is not desired. An arbitrary command may be invoked by placing the -- token to separate the command from the rest of the arguments.

The following example creates an environment containing Python and NumPy, building or downloading any missing package, and runs the python3 command in that environment:

guix shell python python-numpy -- python3

Note that it is necessary to include the main python package in this command even if it is already installed into your environment. This is so that the shell environment knows to set PYTHONPATH and other related variables. The shell environment cannot check the previously installed environment, because then it would be non-deterministic. This is true for most libraries: their corresponding language package should be included in the shell invocation.

Note: guix shell can be also be used as a script interpreter, also known as shebang. Here is an example self-contained Python script making use of this feature:

#!/usr/bin/env -S guix shell python python-numpy -- python3
import numpy
print("This is numpy", numpy.version.version)

You may pass any guix shell option, but there’s one caveat: the Linux kernel has a limit of 127 bytes on shebang length.

Development environments can be created as in the example below, which spawns an interactive shell containing all the dependencies and environment variables needed to work on Inkscape:

guix shell --development inkscape

Exiting the shell places the user back in the original environment before guix shell was invoked. The next garbage collection (see Invoking guix gc) may clean up packages that were installed in the environment and that are no longer used outside of it.

As an added convenience, guix shell will try to do what you mean when it is invoked interactively without any other arguments as in:

guix shell

If it finds a manifest.scm in the current working directory or any of its parents, it uses this manifest as though it was given via --manifest. Likewise, if it finds a guix.scm in the same directories, it uses it to build a development profile as though both --development and --file were present. In either case, the file will only be loaded if the directory it resides in is listed in ~/.config/guix/shell-authorized-directories. This provides an easy way to define, share, and enter development environments.

By default, the shell session or command runs in an augmented environment, where the new packages are added to search path environment variables such as PATH. You can, instead, choose to create an isolated environment containing nothing but the packages you asked for. Passing the --pure option clears environment variable definitions found in the parent environment¹⁴; passing --container goes one step further by spawning a container isolated from the rest of the system:

guix shell --container emacs gcc-toolchain

The command above spawns an interactive shell in a container where nothing but emacs, gcc-toolchain, and their dependencies is available. The container lacks network access and shares no files other than the current working directory with the surrounding environment. This is useful to prevent access to system-wide resources such as /usr/bin on foreign distros.

This --container option can also prove useful if you wish to run a security-sensitive application, such as a web browser, in an isolated environment. For example, the command below launches Ungoogled-Chromium in an isolated environment, which:

• shares network access with the host
• inherits host’s environment variables DISPLAY and XAUTHORITY
• has access to host’s authentication records from the XAUTHORITY file
• has no information about host’s current directory

guix shell --container --network --no-cwd ungoogled-chromium \
  --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \
  --preserve='^DISPLAY$' -- chromium

guix shell defines the GUIX_ENVIRONMENT variable in the shell it spawns; its value is the file name of the profile of this environment. This allows users to, say, define a specific prompt for development environments in their .bashrc (see Bash Startup Files in The GNU Bash Reference Manual):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

... or to browse the profile:

$ ls "$GUIX_ENVIRONMENT/bin"

The available options are summarized below.

--check

Set up the environment and check whether the shell would clobber environment variables. It’s a good idea to use this option the first time you run guix shell for an interactive session to make sure your setup is correct.

For example, if the shell modifies the PATH environment variable, report it since you would get a different environment than what you asked for.

Such problems usually indicate that the shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in ~/.bash_profile and not in ~/.bashrc—the former is sourced only by log-in shells. See Bash Startup Files in The GNU Bash Reference Manual, for details on Bash start-up files.

--development

-D

Cause guix shell to include in the environment the dependencies of the following package rather than the package itself. This can be combined with other packages. For instance, the command below starts an interactive shell containing the build-time dependencies of GNU Guile, plus Autoconf, Automake, and Libtool:

guix shell -D guile autoconf automake libtool

--expression=expr

-e expr

Create an environment for the package or list of packages that expr evaluates to.

For example, running:

guix shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

starts a shell with the environment for this specific variant of the PETSc package.

Running:

guix shell -e '(@ (gnu) %base-packages)'

starts a shell with all the base system packages available.

The above commands only use the default output of the given packages. To select other outputs, two element tuples can be specified:

guix shell -e '(list (@ (gnu packages bash) bash) "include")'

See package->development-manifest, for information on how to write a manifest for the development environment of a package.

--file=file

-f file

Create an environment containing the package or list of packages that the code within file evaluates to.

As an example, file might contain a definition like this (see Defining Packages):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

With the file above, you can enter a development environment for GDB by running:

guix shell -D -f gdb-devel.scm

--manifest=file

-m file

Create an environment for the packages contained in the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

This is similar to the same-named option in guix package (see --manifest) and uses the same manifest files.

See Writing Manifests, for information on how to write a manifest. See --export-manifest below on how to obtain a first manifest.

--export-manifest

Write to standard output a manifest suitable for --manifest corresponding to given command-line options.

This is a way to “convert” command-line arguments into a manifest. For example, imagine you are tired of typing long lines and would like to get a manifest equivalent to this command line:

guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

Just add --export-manifest to the command line above:

guix shell --export-manifest \
  -D guile git emacs emacs-geiser emacs-geiser-guile

... and you get a manifest along these lines:

(concatenate-manifests
  (list (specifications->manifest
          (list "git"
                "emacs"
                "emacs-geiser"
                "emacs-geiser-guile"))
        (package->development-manifest
          (specification->package "guile"))))

You can store it into a file, say manifest.scm, and from there pass it to guix shell or indeed pretty much any guix command:

guix shell -m manifest.scm

Voilà, you’ve converted a long command line into a manifest! That conversion process honors package transformation options (see Package Transformation Options) so it should be lossless.

--profile=profile

-p profile

Create an environment containing the packages installed in profile. Use guix package (see Invoking guix package) to create and manage profiles.

--pure

Unset existing environment variables when building the new environment, except those specified with --preserve (see below). This has the effect of creating an environment in which search paths only contain package inputs.

--preserve=regexp

-E regexp

When used alongside --pure, preserve the environment variables matching regexp—in other words, put them on a “white list” of environment variables that must be preserved. This option can be repeated several times.

guix shell --pure --preserve=^SLURM openmpi … \
  -- mpirun …

This example runs mpirun in a context where the only environment variables defined are PATH, environment variables whose name starts with ‘SLURM’, as well as the usual “precious” variables (HOME, USER, etc.).

--search-paths

Display the environment variable definitions that make up the environment.

--system=system

-s system

Attempt to build for system—e.g., i686-linux.

--container ¶

-C

Run command within an isolated container. The current working directory outside the container is mapped inside the container. Additionally, unless overridden with --user, a dummy home directory is created that matches the current user’s home directory, and /etc/passwd is configured accordingly.

The spawned process runs as the current user outside the container. Inside the container, it has the same UID and GID as the current user, unless --user is passed (see below).

--network

-N

For containers, share the network namespace with the host system. Containers created without this flag only have access to the loopback device.

--link-profile

-P

For containers, link the environment profile to ~/.guix-profile within the container and set GUIX_ENVIRONMENT to that. This is equivalent to making ~/.guix-profile a symlink to the actual profile within the container. Linking will fail and abort the environment if the directory already exists, which will certainly be the case if guix shell was invoked in the user’s home directory.

Certain packages are configured to look in ~/.guix-profile for configuration files and data;¹⁵ --link-profile allows these programs to behave as expected within the environment.

--user=user

-u user

For containers, use the username user in place of the current user. The generated /etc/passwd entry within the container will contain the name user, the home directory will be /home/user, and no user GECOS data will be copied. Furthermore, the UID and GID inside the container are 1000. user need not exist on the system.

Additionally, any shared or exposed path (see --share and --expose respectively) whose target is within the current user’s home directory will be remapped relative to /home/USER; this includes the automatic mapping of the current working directory.

# will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
cd $HOME/wd
guix shell --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

While this will limit the leaking of user identity through home paths and each of the user fields, this is only one useful component of a broader privacy/anonymity solution—not one in and of itself.

--no-cwd

For containers, the default behavior is to share the current working directory with the isolated container and immediately change to that directory within the container. If this is undesirable, --no-cwd will cause the current working directory to not be automatically shared and will change to the user’s home directory within the container instead. See also --user.

--expose=source[=target]

--share=source[=target]

For containers, --expose (resp. --share) exposes the file system source from the host system as the read-only (resp. writable) file system target within the container. If target is not specified, source is used as the target mount point in the container.

The example below spawns a Guile REPL in a container in which the user’s home directory is accessible read-only via the /exchange directory:

guix shell --container --expose=$HOME=/exchange guile -- guile

--symlink=spec

-S spec

For containers, create the symbolic links specified by spec, as documented in pack-symlink-option.

--emulate-fhs

-F

When used with --container, emulate a Filesystem Hierarchy Standard (FHS) configuration within the container, providing /bin, /lib, and other directories and files specified by the FHS.

As Guix deviates from the FHS specification, this option sets up the container to more closely mimic that of other GNU/Linux distributions. This is useful for reproducing other development environments, testing, and using programs which expect the FHS specification to be followed. With this option, the container will include a version of glibc that will read /etc/ld.so.cache within the container for the shared library cache (contrary to glibc in regular Guix usage) and set up the expected FHS directories: /bin, /etc, /lib, and /usr from the container’s profile.

--nesting

-W

When used with --container, provide Guix inside the container and arrange so that it can interact with the build daemon that runs outside the container. This is useful if you want, within your isolated container, to create other containers, as in this sample session:

$ guix shell -CW coreutils
[env]$ guix shell -C guile -- guile -c '(display "hello!\n")'
hello!
[env]$ exit

The session above starts a container with coreutils programs available in PATH. From there, we spawn guix shell to create a nested container that provides nothing but Guile.

Another example is evaluating a guix.scm file that is untrusted, as shown here:

guix shell -CW -- guix build -f guix.scm

The guix build command as executed above can only access the current directory.

Under the hood, the -W option does several things:

• map the daemon’s socket (by default /var/guix/daemon-socket/socket) inside the container;
• map the whole store (by default /gnu/store) inside the container such that store items made available by nested guix invocations are visible;
• add the currently-used guix command to the profile in the container, such that guix describe returns the same state inside and outside the container;
• share the cache (by default ~/.cache/guix) with the host, to speed up operations such as guix time-machine and guix shell.

--rebuild-cache ¶

In most cases, guix shell caches the environment so that subsequent uses are instantaneous. Least-recently used cache entries are periodically removed. The cache is also invalidated, when using --file or --manifest, anytime the corresponding file is modified.

The --rebuild-cache forces the cached environment to be refreshed. This is useful when using --file or --manifest and the guix.scm or manifest.scm file has external dependencies, or if its behavior depends, say, on environment variables.

--root=file ¶

-r file

Make file a symlink to the profile for this environment, and register it as a garbage collector root.

This is useful if you want to protect your environment from garbage collection, to make it “persistent”.

When this option is omitted, guix shell caches profiles so that subsequent uses of the same environment are instantaneous—this is comparable to using --root except that guix shell takes care of periodically removing the least-recently used garbage collector roots.

In some cases, guix shell does not cache profiles—e.g., if transformation options such as --with-latest are used. In those cases, the environment is protected from garbage collection only for the duration of the guix shell session. This means that next time you recreate the same environment, you could have to rebuild or re-download packages.

See Invoking guix gc, for more on GC roots.

guix shell also supports all of the common build options that guix build supports (see Common Build Options) as well as package transformation options (see Package Transformation Options).

7.2 Invoking guix environment

The purpose of guix environment is to assist in creating development environments.

Deprecation warning: The guix environment command is deprecated in favor of guix shell, which performs similar functions but is more convenient to use. See Invoking guix shell.

Being deprecated, guix environment is slated for eventual removal, but the Guix project is committed to keeping it until May 1st, 2023. Please get in touch with us at guix-devel@gnu.org if you would like to discuss it.

The general syntax is:

guix environment options package…

The following example spawns a new shell set up for the development of GNU Guile:

guix environment guile

If the needed dependencies are not built yet, guix environment automatically builds them. The environment of the new shell is an augmented version of the environment that guix environment was run in. It contains the necessary search paths for building the given package added to the existing environment variables. To create a “pure” environment, in which the original environment variables have been unset, use the --pure option¹⁶.

Exiting from a Guix environment is the same as exiting from the shell, and will place the user back in the old environment before guix environment was invoked. The next garbage collection (see Invoking guix gc) will clean up packages that were installed from within the environment and are no longer used outside of it.

guix environment defines the GUIX_ENVIRONMENT variable in the shell it spawns; its value is the file name of the profile of this environment. This allows users to, say, define a specific prompt for development environments in their .bashrc (see Bash Startup Files in The GNU Bash Reference Manual):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

... or to browse the profile:

$ ls "$GUIX_ENVIRONMENT/bin"

Additionally, more than one package may be specified, in which case the union of the inputs for the given packages are used. For example, the command below spawns a shell where all of the dependencies of both Guile and Emacs are available:

guix environment guile emacs

Sometimes an interactive shell session is not desired. An arbitrary command may be invoked by placing the -- token to separate the command from the rest of the arguments:

guix environment guile -- make -j4

In other situations, it is more convenient to specify the list of packages needed in the environment. For example, the following command runs python from an environment containing Python 3 and NumPy:

guix environment --ad-hoc python-numpy python -- python3

Furthermore, one might want the dependencies of a package and also some additional packages that are not build-time or runtime dependencies, but are useful when developing nonetheless. Because of this, the --ad-hoc flag is positional. Packages appearing before --ad-hoc are interpreted as packages whose dependencies will be added to the environment. Packages appearing after are interpreted as packages that will be added to the environment directly. For example, the following command creates a Guix development environment that additionally includes Git and strace:

guix environment --pure guix --ad-hoc git strace

Sometimes it is desirable to isolate the environment as much as possible, for maximal purity and reproducibility. In particular, when using Guix on a host distro that is not Guix System, it is desirable to prevent access to /usr/bin and other system-wide resources from the development environment. For example, the following command spawns a Guile REPL in a “container” where only the store and the current working directory are mounted:

guix environment --ad-hoc --container guile -- guile

Note: The --container option requires Linux-libre 3.19 or newer.

Another typical use case for containers is to run security-sensitive applications such as a web browser. To run Eolie, we must expose and share some files and directories; we include nss-certs and expose /etc/ssl/certs/ for HTTPS authentication; finally we preserve the DISPLAY environment variable since containerized graphical applications won’t display without it.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

The available options are summarized below.

--check

Set up the environment and check whether the shell would clobber environment variables. See --check, for more info.

--root=file ¶

-r file

Make file a symlink to the profile for this environment, and register it as a garbage collector root.

This is useful if you want to protect your environment from garbage collection, to make it “persistent”.

When this option is omitted, the environment is protected from garbage collection only for the duration of the guix environment session. This means that next time you recreate the same environment, you could have to rebuild or re-download packages. See Invoking guix gc, for more on GC roots.

--expression=expr

-e expr

Create an environment for the package or list of packages that expr evaluates to.

For example, running:

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

starts a shell with the environment for this specific variant of the PETSc package.

Running:

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

starts a shell with all the base system packages available.

The above commands only use the default output of the given packages. To select other outputs, two element tuples can be specified:

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=file

-l file

Create an environment for the package or list of packages that the code within file evaluates to.

As an example, file might contain a definition like this (see Defining Packages):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

--manifest=file

-m file

Create an environment for the packages contained in the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

This is similar to the same-named option in guix package (see --manifest) and uses the same manifest files.

See guix shell --export-manifest, for information on how to “convert” command-line options into a manifest.

--ad-hoc

Include all specified packages in the resulting environment, as if an ad hoc package were defined with them as inputs. This option is useful for quickly creating an environment without having to write a package expression to contain the desired inputs.

For instance, the command:

guix environment --ad-hoc guile guile-sdl -- guile

runs guile in an environment where Guile and Guile-SDL are available.

Note that this example implicitly asks for the default output of guile and guile-sdl, but it is possible to ask for a specific output—e.g., glib:bin asks for the bin output of glib (see Packages with Multiple Outputs).

This option may be composed with the default behavior of guix environment. Packages appearing before --ad-hoc are interpreted as packages whose dependencies will be added to the environment, the default behavior. Packages appearing after are interpreted as packages that will be added to the environment directly.

--profile=profile

-p profile

Create an environment containing the packages installed in profile. Use guix package (see Invoking guix package) to create and manage profiles.

--pure

Unset existing environment variables when building the new environment, except those specified with --preserve (see below). This has the effect of creating an environment in which search paths only contain package inputs.

--preserve=regexp

-E regexp

When used alongside --pure, preserve the environment variables matching regexp—in other words, put them on a “white list” of environment variables that must be preserved. This option can be repeated several times.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

This example runs mpirun in a context where the only environment variables defined are PATH, environment variables whose name starts with ‘SLURM’, as well as the usual “precious” variables (HOME, USER, etc.).

--search-paths

Display the environment variable definitions that make up the environment.

--system=system

-s system

Attempt to build for system—e.g., i686-linux.

--container ¶

-C

Run command within an isolated container. The current working directory outside the container is mapped inside the container. Additionally, unless overridden with --user, a dummy home directory is created that matches the current user’s home directory, and /etc/passwd is configured accordingly.

The spawned process runs as the current user outside the container. Inside the container, it has the same UID and GID as the current user, unless --user is passed (see below).

--network

-N

For containers, share the network namespace with the host system. Containers created without this flag only have access to the loopback device.

--link-profile

-P

For containers, link the environment profile to ~/.guix-profile within the container and set GUIX_ENVIRONMENT to that. This is equivalent to making ~/.guix-profile a symlink to the actual profile within the container. Linking will fail and abort the environment if the directory already exists, which will certainly be the case if guix environment was invoked in the user’s home directory.

Certain packages are configured to look in ~/.guix-profile for configuration files and data;¹⁷ --link-profile allows these programs to behave as expected within the environment.

--user=user

-u user

For containers, use the username user in place of the current user. The generated /etc/passwd entry within the container will contain the name user, the home directory will be /home/user, and no user GECOS data will be copied. Furthermore, the UID and GID inside the container are 1000. user need not exist on the system.

Additionally, any shared or exposed path (see --share and --expose respectively) whose target is within the current user’s home directory will be remapped relative to /home/USER; this includes the automatic mapping of the current working directory.

# will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
cd $HOME/wd
guix environment --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

While this will limit the leaking of user identity through home paths and each of the user fields, this is only one useful component of a broader privacy/anonymity solution—not one in and of itself.

--no-cwd

For containers, the default behavior is to share the current working directory with the isolated container and immediately change to that directory within the container. If this is undesirable, --no-cwd will cause the current working directory to not be automatically shared and will change to the user’s home directory within the container instead. See also --user.

--expose=source[=target]

--share=source[=target]

For containers, --expose (resp. --share) exposes the file system source from the host system as the read-only (resp. writable) file system target within the container. If target is not specified, source is used as the target mount point in the container.

The example below spawns a Guile REPL in a container in which the user’s home directory is accessible read-only via the /exchange directory:

guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile

--emulate-fhs

-F

For containers, emulate a Filesystem Hierarchy Standard (FHS) configuration within the container, see the official specification. As Guix deviates from the FHS specification, this option sets up the container to more closely mimic that of other GNU/Linux distributions. This is useful for reproducing other development environments, testing, and using programs which expect the FHS specification to be followed. With this option, the container will include a version of glibc which will read /etc/ld.so.cache within the container for the shared library cache (contrary to glibc in regular Guix usage) and set up the expected FHS directories: /bin, /etc, /lib, and /usr from the container’s profile.

guix environment also supports all of the common build options that guix build supports (see Common Build Options) as well as package transformation options (see Package Transformation Options).

7.3 Invoking guix pack

Occasionally you want to pass software to people who are not (yet!) lucky enough to be using Guix. You’d tell them to run guix package -i something, but that’s not possible in this case. This is where guix pack comes in.

Note: If you are looking for ways to exchange binaries among machines that already run Guix, see Invoking guix copy, Invoking guix publish, and Invoking guix archive.

The guix pack command creates a shrink-wrapped pack or software bundle: it creates a tarball or some other archive containing the binaries of the software you’re interested in, and all its dependencies. The resulting archive can be used on any machine that does not have Guix, and people can run the exact same binaries as those you have with Guix. The pack itself is created in a bit-reproducible fashion, so anyone can verify that it really contains the build results that you pretend to be shipping.

For example, to create a bundle containing Guile, Emacs, Geiser, and all their dependencies, you can run:

$ guix pack guile emacs emacs-geiser
…
/gnu/store/…-pack.tar.gz

The result here is a tarball containing a /gnu/store directory with all the relevant packages. The resulting tarball contains a profile with the three packages of interest; the profile is the same as would be created by guix package -i. It is this mechanism that is used to create Guix’s own standalone binary tarball (see Binary Installation).

Users of this pack would have to run /gnu/store/…-profile/bin/guile to run Guile, which you may find inconvenient. To work around it, you can create, say, a /opt/gnu/bin symlink to the profile:

guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser

That way, users can happily type /opt/gnu/bin/guile and enjoy.

What if the recipient of your pack does not have root privileges on their machine, and thus cannot unpack it in the root file system? In that case, you will want to use the --relocatable option (see below). This option produces relocatable binaries, meaning they can be placed anywhere in the file system hierarchy: in the example above, users can unpack your tarball in their home directory and directly run ./opt/gnu/bin/guile.

Alternatively, you can produce a pack in the Docker image format using the following command:

guix pack -f docker -S /bin=bin guile guile-readline

The result is a tarball that can be passed to the docker load command, followed by docker run:

docker load < file
docker run -ti guile-guile-readline /bin/guile

where file is the image returned by guix pack, and guile-guile-readline is its “image tag”. See the Docker documentation for more information.

Yet another option is to produce a SquashFS image with the following command:

guix pack -f squashfs bash guile emacs emacs-geiser

The result is a SquashFS file system image that can either be mounted or directly be used as a file system container image with the Singularity container execution environment, using commands like singularity shell or singularity exec.

Another format internally based on SquashFS is AppImage. An AppImage file can be created and executed without any special privileges:

file=$(guix pack -f appimage --entry-point=bin/guile guile)
$file --help

Several command-line options allow you to customize your pack:

--format=format

-f format

Produce a pack in the given format.

The available formats are:

tarball

This is the default format. It produces a tarball containing all the specified binaries and symlinks.

docker

This produces a tarball that follows the Docker Image Specification. By default, the “repository name” as it appears in the output of the docker images command is computed from package names passed on the command line or in the manifest file. Alternatively, the “repository name” can also be configured via the --image-tag option. Refer to --help-docker-format for more information on such advanced options.

squashfs

This produces a SquashFS image containing all the specified binaries and symlinks, as well as empty mount points for virtual file systems like procfs.

Note: Singularity requires you to provide /bin/sh in the image. For that reason, guix pack -f squashfs always implies -S /bin=bin. Thus, your guix pack invocation must always start with something like:

guix pack -f squashfs bash …

If you forget the bash (or similar) package, singularity run and singularity exec will fail with an unhelpful “no such file or directory” message.

deb ¶

This produces a Debian archive (a package with the ‘.deb’ file extension) containing all the specified binaries and symbolic links, that can be installed on top of any dpkg-based GNU(/Linux) distribution. Advanced options can be revealed via the --help-deb-format option. They allow embedding control files for more fine-grained control, such as activating specific triggers or providing a maintainer configure script to run arbitrary setup code upon installation.

guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello

Note: Because archives produced with guix pack contain a collection of store items and because each dpkg package must not have conflicting files, in practice that means you likely won’t be able to install more than one such archive on a given system. You can nonetheless pack as many Guix packages as you want in one such archive.

Warning: dpkg will assume ownership of any files contained in the pack that it does not know about. It is unwise to install Guix-produced ‘.deb’ files on a system where /gnu/store is shared by other software, such as a Guix installation or other, non-deb packs.

rpm ¶

This produces an RPM archive (a package with the ‘.rpm’ file extension) containing all the specified binaries and symbolic links, that can be installed on top of any RPM-based GNU/Linux distribution. The RPM format embeds checksums for every file it contains, which the rpm command uses to validate the integrity of the archive.

Advanced RPM-related options are revealed via the --help-rpm-format option. These options allow embedding maintainer scripts that can run before or after the installation of the RPM archive, for example.

The RPM format supports relocatable packages via the --prefix option of the rpm command, which can be handy to install an RPM package to a specific prefix.

guix pack -f rpm -R -C xz -S /usr/bin/hello=bin/hello hello

sudo rpm --install --prefix=/opt /gnu/store/...-hello.rpm

Note: Contrary to Debian packages, conflicting but identical files in RPM packages can be installed simultaneously, which means multiple guix pack-produced RPM packages can usually be installed side by side without any problem.

Warning: rpm assumes ownership of any files contained in the pack, which means it will remove /gnu/store upon uninstalling a Guix-generated RPM package, unless the RPM package was installed with the --prefix option of the rpm command. It is unwise to install Guix-produced ‘.rpm’ packages on a system where /gnu/store is shared by other software, such as a Guix installation or other, non-rpm packs.

appimage ¶

This produces an AppImage file with the ‘.AppImage’ extension. AppImage is a SquashFS volume prefixed with a runtime that mounts the SquashFS file system and executes the binary provided with --entry-point. This results in a self-contained archive that bundles the software and all its requirements into a single file. When the file is made executable it runs the packaged software.

guix pack -f appimage --entry-point=bin/vlc vlc

The runtime used by AppImages invokes the fusermount3 command to mount the image quickly. If that command is unavailable, the AppImage fails to run, but it can still be started by passing the --appimage-extract-and-run flag.

Warning: When building an AppImage, always pass the --relocatable option (or -R, or -RR) to make sure the image can be used on systems where Guix is not installed. A warning is printed when this option is not used.

guix pack -f appimage --entry-point=bin/hello --relocatable hello

Note: The resulting AppImage does not conform to the complete standard as it currently does not contain a .DirIcon file. This does not impact functionality of the AppImage itself, but possibly that of software used to manage AppImages.

Note: As the generated AppImage packages the complete dependency graph, it will be larger than comparable AppImage files found online, which depend on host system libraries.

--relocatable

-R

Produce relocatable binaries—i.e., binaries that can be placed anywhere in the file system hierarchy and run from there.

When this option is passed once, the resulting binaries require support for user namespaces in the kernel Linux; when passed twice¹⁸, relocatable binaries fall to back to other techniques if user namespaces are unavailable, and essentially work anywhere—see below for the implications.

For example, if you create a pack containing Bash with:

guix pack -RR -S /mybin=bin bash

... you can copy that pack to a machine that lacks Guix, and from your home directory as a normal user, run:

tar xf pack.tar.gz
./mybin/sh

In that shell, if you type ls /gnu/store, you’ll notice that /gnu/store shows up and contains all the dependencies of bash, even though the machine actually lacks /gnu/store altogether! That is probably the simplest way to deploy Guix-built software on a non-Guix machine.

Note: By default, relocatable binaries rely on the user namespace feature of the kernel Linux, which allows unprivileged users to mount or change root. Old versions of Linux did not support it, and some GNU/Linux distributions turn it off.

To produce relocatable binaries that work even in the absence of user namespaces, pass --relocatable or -R twice. In that case, binaries will try user namespace support and fall back to another execution engine if user namespaces are not supported. The following execution engines are supported:

default

Try user namespaces and fall back to PRoot if user namespaces are not supported (see below).

performance

Try user namespaces and fall back to Fakechroot if user namespaces are not supported (see below).

userns

Run the program through user namespaces and abort if they are not supported.

proot

Run through PRoot. The PRoot program provides the necessary support for file system virtualization. It achieves that by using the ptrace system call on the running program. This approach has the advantage to work without requiring special kernel support, but it incurs run-time overhead every time a system call is made.

fakechroot

Run through Fakechroot. Fakechroot virtualizes file system accesses by intercepting calls to C library functions such as open, stat, exec, and so on. Unlike PRoot, it incurs very little overhead. However, it does not always work: for example, some file system accesses made from within the C library are not intercepted, and file system accesses made via direct syscalls are not intercepted either, leading to erratic behavior.

When running a wrapped program, you can explicitly request one of the execution engines listed above by setting the GUIX_EXECUTION_ENGINE environment variable accordingly.

--entry-point=command

Use command as the entry point of the resulting pack, if the pack format supports it—currently docker, appimage, and squashfs (Singularity) support it. command must be relative to the profile contained in the pack.

The entry point specifies the command that tools like docker run or singularity run automatically start by default. For example, you can do:

guix pack -f docker --entry-point=bin/guile guile

The resulting pack can easily be loaded and docker run with no extra arguments will spawn bin/guile:

docker load -i pack.tar.gz
docker run image-id

--entry-point-argument=command

-A command

Use command as an argument to entry point of the resulting pack. This option is only valid in conjunction with --entry-point and can appear multiple times on the command line.

guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile

--max-layers=n

Specifies the maximum number of Docker image layers allowed when building an image.

guix pack -f docker --max-layers=100 guile

This option allows you to limit the number of layers in a Docker image. Docker images are comprised of multiple layers, and each layer adds to the overall size and complexity of the image. By setting a maximum number of layers, you can control the following effects:

• Disk Usage: Increasing the number of layers can help optimize the disk space required to store multiple images built with a similar package graph.
• Pulling: When transferring images between different nodes or systems, having more layers can reduce the time required to pull the image.

--expression=expr

-e expr

Consider the package expr evaluates to.

This has the same purpose as the same-named option in guix build (see --expression in guix build).

--file=file

Build a pack containing the package or other object the code within file evaluates to.

This has the same purpose as the same-named option in guix build (see --file in guix build), but it has no shorthand, because -f already means --format.

--manifest=file

-m file

Use the packages contained in the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

This has a similar purpose as the same-named option in guix package (see --manifest) and uses the same manifest files. It allows you to define a collection of packages once and use it both for creating profiles and for creating archives for use on machines that do not have Guix installed. Note that you can specify either a manifest file or a list of packages, but not both.

See Writing Manifests, for information on how to write a manifest. See guix shell --export-manifest, for information on how to “convert” command-line options into a manifest.

--system=system

-s system

Attempt to build for system—e.g., i686-linux—instead of the system type of the build host.

--target=triplet ¶

Cross-build for triplet, which must be a valid GNU triplet, such as "aarch64-linux-gnu" (see GNU configuration triplets in Autoconf).

--compression=tool

-C tool

Compress the resulting tarball using tool—one of gzip, zstd, bzip2, xz, lzip, or none for no compression.

--symlink=spec

-S spec

Add the symlinks specified by spec to the pack. This option can appear several times.

spec has the form source=target, where source is the symlink that will be created and target is the symlink target.

For instance, -S /opt/gnu/bin=bin creates a /opt/gnu/bin symlink pointing to the bin sub-directory of the profile.

--save-provenance

Save provenance information for the packages passed on the command line. Provenance information includes the URL and commit of the channels in use (see Channels).

Provenance information is saved in the /gnu/store/…-profile/manifest file in the pack, along with the usual package metadata—the name and version of each package, their propagated inputs, and so on. It is useful information to the recipient of the pack, who then knows how the pack was (supposedly) obtained.

This option is not enabled by default because, like timestamps, provenance information contributes nothing to the build process. In other words, there is an infinity of channel URLs and commit IDs that can lead to the same pack. Recording such “silent” metadata in the output thus potentially breaks the source-to-binary bitwise reproducibility property.

--root=file ¶

-r file

Make file a symlink to the resulting pack, and register it as a garbage collector root.

--localstatedir

--profile-name=name

Include the “local state directory”, /var/guix, in the resulting pack, and notably the /var/guix/profiles/per-user/root/name profile—by default name is guix-profile, which corresponds to ~root/.guix-profile.

/var/guix contains the store database (see The Store) as well as garbage-collector roots (see Invoking guix gc). Providing it in the pack means that the store is “complete” and manageable by Guix; not providing it in the pack means that the store is “dead”: items cannot be added to it or removed from it after extraction of the pack.

One use case for this is the Guix self-contained binary tarball (see Binary Installation).

--derivation

-d

Print the name of the derivation that builds the pack.

--bootstrap

Use the bootstrap binaries to build the pack. This option is only useful to Guix developers.

In addition, guix pack supports all the common build options (see Common Build Options) and all the package transformation options (see Package Transformation Options).

7.4 The GCC toolchain

If you need a complete toolchain for compiling and linking C or C++ source code, use the gcc-toolchain package. This package provides a complete GCC toolchain for C/C++ development, including GCC itself, the GNU C Library (headers and binaries, plus debugging symbols in the debug output), Binutils, and a linker wrapper.

The wrapper’s purpose is to inspect the -L and -l switches passed to the linker, add corresponding -rpath arguments, and invoke the actual linker with this new set of arguments. You can instruct the wrapper to refuse to link against libraries not in the store by setting the GUIX_LD_WRAPPER_ALLOW_IMPURITIES environment variable to no.

The package gfortran-toolchain provides a complete GCC toolchain for Fortran development. For other languages, please use ‘guix search gcc toolchain’ (see Invoking guix package).

7.5 Invoking guix git authenticate

The guix git authenticate command authenticates a Git checkout following the same rule as for channels (see channel authentication). That is, starting from a given commit, it ensures that all subsequent commits are signed by an OpenPGP key whose fingerprint appears in the .guix-authorizations file of its parent commit(s).

You will find this command useful if you maintain a channel. But in fact, this authentication mechanism is useful in a broader context, so you might want to use it for Git repositories that have nothing to do with Guix.

The general syntax is:

guix git authenticate commit signer [options…]

By default, this command authenticates the Git checkout in the current directory; it outputs nothing and exits with exit code zero on success and non-zero on failure. commit above denotes the first commit where authentication takes place, and signer is the OpenPGP fingerprint of public key used to sign commit. Together, they form a channel introduction (see channel introduction). On your first successful run, the introduction is recorded in the .git/config file of your checkout, allowing you to omit them from subsequent invocations:

guix git authenticate [options…]

Should you have branches that require different introductions, you can specify them directly in .git/config. For example, if the branch called personal-fork has a different introduction than other branches, you can extend .git/config along these lines:

[guix "authentication-personal-fork"]
	introduction-commit = cabba936fd807b096b48283debdcddccfea3900d
	introduction-signer = C0FF EECA BBA9 E6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
	keyring = keyring

The first run also attempts to install pre-push and post-merge hooks, such that guix git authenticate is invoked as soon as you run git push, git pull, and related commands; it does not overwrite preexisting hooks though.

The command-line options described below allow you to fine-tune the process.

--repository=directory

-r directory

Open the Git repository in directory instead of the current directory.

--keyring=reference

-k reference

Load OpenPGP keyring from reference, the reference of a branch such as origin/keyring or my-keyring. The branch must contain OpenPGP public keys in .key files, either in binary form or “ASCII-armored”. By default the keyring is loaded from the branch named keyring.

--end=commit

Authenticate revisions up to commit.

--stats

Display commit signing statistics upon completion.

--cache-key=key

Previously-authenticated commits are cached in a file under ~/.cache/guix/authentication. This option forces the cache to be stored in file key in that directory.

--historical-authorizations=file

By default, any commit whose parent commit(s) lack the .guix-authorizations file is considered inauthentic. In contrast, this option considers the authorizations in file for any commit that lacks .guix-authorizations. The format of file is the same as that of .guix-authorizations (see .guix-authorizations format).

8.1 Package Modules

From a programming viewpoint, the package definitions of the GNU distribution are provided by Guile modules in the (gnu packages …) name space¹⁹ (see Guile modules in GNU Guile Reference Manual). For instance, the (gnu packages emacs) module exports a variable named emacs, which is bound to a <package> object (see Defining Packages).

The (gnu packages …) module name space is automatically scanned for packages by the command-line tools. For instance, when running guix install emacs, all the (gnu packages …) modules are scanned until one that exports a package object whose name is emacs is found. This package search facility is implemented in the (gnu packages) module.

Users can store package definitions in modules with different names—e.g., (my-packages emacs)²⁰. There are two ways to make these package definitions visible to the user interfaces:

1. By adding the directory containing your package modules to the search path with the -L flag of guix package and other commands (see Common Build Options), or by setting the GUIX_PACKAGE_PATH environment variable described below.
2. By defining a channel and configuring guix pull so that it pulls from it. A channel is essentially a Git repository containing package modules. See Channels, for more information on how to define and use channels.

GUIX_PACKAGE_PATH works similarly to other search path variables:

Environment Variable: GUIX_PACKAGE_PATH

This is a colon-separated list of directories to search for additional package modules. Directories listed in this variable take precedence over the own modules of the distribution.

The distribution is fully bootstrapped and self-contained: each package is built based solely on other packages in the distribution. The root of this dependency graph is a small set of bootstrap binaries, provided by the (gnu packages bootstrap) module. For more information on bootstrapping, see Bootstrapping.

8.2 Defining Packages

The high-level interface to package definitions is implemented in the (guix packages) and (guix build-system) modules. As an example, the package definition, or recipe, for the GNU Hello package looks like this:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Without being a Scheme expert, the reader may have guessed the meaning of the various fields here. This expression binds the variable hello to a <package> object, which is essentially a record (see Scheme records in GNU Guile Reference Manual). This package object can be inspected using procedures found in the (guix packages) module; for instance, (package-name hello) returns—surprise!—"hello".

With luck, you may be able to import part or all of the definition of the package you are interested in from another repository, using the guix import command (see Invoking guix import).

In the example above, hello is defined in a module of its own, (gnu packages hello). Technically, this is not strictly necessary, but it is convenient to do so: all the packages defined in modules under (gnu packages …) are automatically known to the command-line tools (see Package Modules).

There are a few points worth noting in the above package definition:

• The source field of the package is an <origin> object (see origin Reference, for the complete reference). Here, the url-fetch method from (guix download) is used, meaning that the source is a file to be downloaded over FTP or HTTP.

  The mirror://gnu prefix instructs url-fetch to use one of the GNU mirrors defined in (guix download).

  The sha256 field specifies the expected SHA256 hash of the file being downloaded. It is mandatory, and allows Guix to check the integrity of the file. The (base32 …) form introduces the base32 representation of the hash. You can obtain this information with guix download (see Invoking guix download) and guix hash (see Invoking guix hash).

  When needed, the origin form can also have a patches field listing patches to be applied, and a snippet field giving a Scheme expression to modify the source code.

• The build-system field specifies the procedure to build the package (see Build Systems). Here, gnu-build-system represents the familiar GNU Build System, where packages may be configured, built, and installed with the usual ./configure && make && make check && make install command sequence.

  When you start packaging non-trivial software, you may need tools to manipulate those build phases, manipulate files, and so on. See Build Utilities, for more on this.

• The arguments field specifies options for the build system (see Build Systems). Here it is interpreted by gnu-build-system as a request run configure with the --enable-silent-rules flag.

  What about these quote (') characters? They are Scheme syntax to introduce a literal list; ' is synonymous with quote. Sometimes you’ll also see ` (a backquote, synonymous with quasiquote) and , (a comma, synonymous with unquote). See quoting in GNU Guile Reference Manual, for details. Here the value of the arguments field is a list of arguments passed to the build system down the road, as with apply (see apply in GNU Guile Reference Manual).

  The hash-colon (#:) sequence defines a Scheme keyword (see Keywords in GNU Guile Reference Manual), and #:configure-flags is a keyword used to pass a keyword argument to the build system (see Coding With Keywords in GNU Guile Reference Manual).

• The inputs field specifies inputs to the build process—i.e., build-time or run-time dependencies of the package. Here, we add an input, a reference to the gawk variable; gawk is itself bound to a <package> object.

  Note that GCC, Coreutils, Bash, and other essential tools do not need to be specified as inputs here. Instead, gnu-build-system takes care of ensuring that they are present (see Build Systems).

  However, any other dependencies need to be specified in the inputs field. Any dependency not specified here will simply be unavailable to the build process, possibly leading to a build failure.

See package Reference, for a full description of possible fields.

Going further: Intimidated by the Scheme language or curious about it? The Cookbook has a short section to get started that recaps some of the things shown above and explains the fundamentals. See A Scheme Crash Course in GNU Guix Cookbook, for more information.

Once a package definition is in place, the package may actually be built using the guix build command-line tool (see Invoking guix build), troubleshooting any build failures you encounter (see Debugging Build Failures). You can easily jump back to the package definition using the guix edit command (see Invoking guix edit). See Packaging Guidelines, for more information on how to test package definitions, and Invoking guix lint, for information on how to check a definition for style conformance. Lastly, see Channels, for information on how to extend the distribution by adding your own package definitions in a “channel”.

Finally, updating the package definition to a new upstream version can be partly automated by the guix refresh command (see Invoking guix refresh).

Behind the scenes, a derivation corresponding to the <package> object is first computed by the package-derivation procedure. That derivation is stored in a .drv file under /gnu/store. The build actions it prescribes may then be realized by using the build-derivations procedure (see The Store).