3.1 Features

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
(note that Guix comes with an Emacs extension to shorten those file
names, see Emacs Prettify.)

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 GuixSD is subject to
transactional upgrades and roll-back
(see Using the Configuration System).

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.

Finally, 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 environment 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 environment).