Newer
Older
Remove the specified @var{package}s.
As for @code{--install}, each @var{package} may specify a version number
and/or output name in addition to the package name. For instance,
@code{-r glibc:debug} would remove the @code{debug} output of
@code{glibc}.
@item --upgrade[=@var{regexp} @dots{}]
@itemx -u [@var{regexp} @dots{}]
Upgrade all the installed packages. If one or more @var{regexp}s are
specified, upgrade only installed packages whose name matches a
@var{regexp}. Also see the @code{--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 @command{guix pull} (@pxref{Invoking guix
pull}).
@item --do-not-upgrade[=@var{regexp} @dots{}]
When used together with the @code{--upgrade} option, do @emph{not}
upgrade any packages whose name matches a @var{regexp}. For example, to
upgrade all packages in the current profile except those containing the
substring ``emacs'':
@example
$ guix package --upgrade . --do-not-upgrade emacs
@end example
@item @anchor{profile-manifest}--manifest=@var{file}
@cindex profile declaration
@cindex profile manifest
Create a new generation of the profile from the manifest object
returned by the Scheme code in @var{file}.
This allows you to @emph{declare} the profile's contents rather than
constructing it through a sequence of @code{--install} and similar
commands. The advantage is that @var{file} can be put under version
control, copied to different machines to reproduce the same profile, and
so on.
@c FIXME: Add reference to (guix profile) documentation when available.
@var{file} must return a @dfn{manifest} object, which is roughly a list
of packages:
(use-package-modules guile emacs)
@findex specifications->manifest
In this example we have to know which modules define the @code{emacs}
and @code{guile-2.0} variables to provide the right
@code{use-package-modules} line, which can be cumbersome. We can
instead provide regular package specifications and let
@code{specifications->manifest} look up the corresponding package
objects, like this:
@example
(specifications->manifest
'("emacs" "guile@@2.2" "guile@@2.2:debug"))
@end example
@cindex rolling back
@cindex undoing transactions
@cindex transactions, undoing
Roll back to the previous @dfn{generation} of the profile---i.e., undo
the last transaction.
When combined with options such as @code{--install}, roll back occurs
before any other actions.
Ludovic Courtès
committed
When rolling back from the first generation that actually contains
installed packages, the profile is made to point to the @dfn{zeroth
generation}, which contains no files apart from its own metadata.
Ludovic Courtès
committed
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.
@item --switch-generation=@var{pattern}
@itemx -S @var{pattern}
Switch to a particular generation defined by @var{pattern}.
@var{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 @code{--roll-back}, use
@code{--switch-generation=+1}.
The difference between @code{--roll-back} and
@code{--switch-generation=-1} is that @code{--switch-generation} will
not make a zeroth generation, so if a specified generation does not
exist, the current generation will not be changed.
@item --search-paths[=@var{kind}]
@cindex search paths
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 @dfn{search paths} for files used by some
of the installed packages.
For example, GCC needs the @code{CPATH} and @code{LIBRARY_PATH}
environment variables to be defined so it can look for headers and
libraries in the user's profile (@pxref{Environment Variables,,, gcc,
Using the GNU Compiler Collection (GCC)}). If GCC and, say, the C
library are installed in the profile, then @code{--search-paths} will
suggest setting these variables to @code{@var{profile}/include} and
@code{@var{profile}/lib}, respectively.
The typical use case is to define these environment variables in the
shell:
@example
$ eval `guix package --search-paths`
@end example
@var{kind} may be one of @code{exact}, @code{prefix}, or @code{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, @var{kind} defaults to @code{exact}.
This option can also be used to compute the @emph{combined} search paths
of several profiles. Consider this example:
@example
$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths
@end example
The last command above reports about the @code{GUILE_LOAD_PATH}
variable, even though, taken individually, neither @file{foo} nor
@file{bar} would lead to that recommendation.
@item --profile=@var{profile}
@itemx -p @var{profile}
Use @var{profile} instead of the user's default profile.
@cindex collisions, in a profile
@cindex colliding packages in profiles
@cindex profile collisions
@item --allow-collisions
Allow colliding packages in the new profile. Use at your own risk!
By default, @command{guix package} reports as an error @dfn{collisions}
in the profile. Collisions happen when two or more different versions
or variants of a given package end up in the profile.
@item --bootstrap
Use the bootstrap Guile to build the profile. This option is only
useful to distribution developers.
@end table
In addition to these actions, @command{guix package} supports the
following options to query the current state of a profile, or the
availability of packages:
@item --search=@var{regexp}
@itemx -s @var{regexp}
@cindex searching for packages
List the available packages whose name, synopsis, or description matches
@var{regexp} (in a case-insensitive fashion), sorted by relevance.
Print all the metadata of matching packages in
@code{recutils} format (@pxref{Top, GNU recutils databases,, recutils,
GNU recutils manual}).
This allows specific fields to be extracted using the @command{recsel}
command, for instance:
@example
$ 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
@end example
Similarly, to show the name of all the packages available under the
terms of the GNU@tie{}LGPL version 3:
@example
$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils
name: gmp
@dots{}
@end example
It is also possible to refine search results using several @code{-s}
flags. For example, the following command returns a list of board
games:
@example
$ guix package -s '\<board\>' -s game | recsel -p name
name: gnubg
@dots{}
@end example
If we were to omit @code{-s game}, we would also get software packages
that deal with printed circuit boards; removing the angle brackets
around @code{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:
@example
$ guix package -s crypto -s library | \
recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
@end example
@noindent
@xref{Selection Expressions,,, recutils, GNU recutils manual}, for more
information on @dfn{selection expressions} for @code{recsel -e}.
@item --show=@var{package}
Show details about @var{package}, taken from the list of available packages, in
@code{recutils} format (@pxref{Top, GNU recutils databases,, recutils, GNU
recutils manual}).
@example
$ guix package --show=python | recsel -p name,version
name: python
version: 2.7.6
name: python
version: 3.3.5
@end example
You may also specify the full name of a package to only get details about a
specific version of it:
@example
$ guix package --show=python@@3.4 | recsel -p name,version
@item --list-installed[=@var{regexp}]
@itemx -I [@var{regexp}]
List the currently installed packages in the specified profile, with the
most recently installed packages shown last. When @var{regexp} is
specified, list only installed packages whose name matches @var{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, @code{out} for the default output,
@code{include} for its headers, etc.), and the path of this package in
the store.
@item --list-available[=@var{regexp}]
@itemx -A [@var{regexp}]
List packages currently available in the distribution for this system
(@pxref{GNU Distribution}). When @var{regexp} is specified, list only
installed packages whose name matches @var{regexp}.
For each package, print the following items separated by tabs: its name,
its version string, the parts of the package (@pxref{Packages with
Multiple Outputs}), and the source location of its definition.
@item --list-generations[=@var{pattern}]
@itemx -l [@var{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 (@pxref{Packages with Multiple Outputs}), and the
location of this package in the store.
When @var{pattern} is used, the command returns only matching
generations. Valid patterns include:
@itemize
@item @emph{Integers and comma-separated integers}. Both patterns denote
generation numbers. For instance, @code{--list-generations=1} returns
the first one.
And @code{--list-generations=1,8,2} outputs three generations in the
specified order. Neither spaces nor trailing commas are allowed.
@item @emph{Ranges}. @code{--list-generations=2..9} prints the
specified generations and everything in between. Note that the start of
It is also possible to omit the endpoint. For example,
@code{--list-generations=2..}, returns all generations starting from the
second one.
@item @emph{Durations}. You can also get the last @emph{N}@tie{}days, weeks,
or months by passing an integer along with the first letter of the
Ludovic Courtès
committed
duration. For example, @code{--list-generations=20d} lists generations
that are up to 20 days old.
@end itemize
@item --delete-generations[=@var{pattern}]
@itemx -d [@var{pattern}]
Ludovic Courtès
committed
When @var{pattern} is omitted, delete all generations except the current
one.
This command accepts the same patterns as @option{--list-generations}.
Ludovic Courtès
committed
When @var{pattern} is specified, delete the matching generations. When
@var{pattern} specifies a duration, generations @emph{older} than the
specified duration match. For instance, @code{--delete-generations=1m}
deletes generations that are more than one month old.
If the current generation matches, it is @emph{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.
Finally, since @command{guix package} may actually start build
processes, it supports all the common build options (@pxref{Common Build
Options}). It also supports package transformation options, such as
@option{--with-source} (@pxref{Package Transformation Options}).
However, note that package transformations are lost when upgrading; to
preserve transformations across upgrades, you should define your own
package variant in a Guile module and add it to @code{GUIX_PACKAGE_PATH}
(@pxref{Defining Packages}).
@node Substitutes
@section Substitutes
@cindex substitutes
@cindex pre-built binaries
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 @dfn{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
(@pxref{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 Server:: One particular source of substitutes.
* Substitute Server Authorization:: How to enable or disable substitutes.
* Substitute Authentication:: How Guix verifies substitutes.
* Proxy Settings:: How to get substitutes via proxy.
* Substitution Failure:: What happens when substitution fails.
* On Trusting Binaries:: How can you trust that binary blob?
@end menu
@node Official Substitute Server
@subsection Official Substitute Server
@cindex hydra
@cindex build farm
The @code{@value{SUBSTITUTE-SERVER}} server is a front-end to an official build farm
that builds packages from Guix continuously for some
architectures, and makes them available as substitutes. This is the
default source of substitutes; it can be overridden by passing the
@option{--substitute-urls} option either to @command{guix-daemon}
(@pxref{daemon-substitute-urls,, @code{guix-daemon --substitute-urls}})
or to client tools such as @command{guix package}
(@pxref{client-substitute-urls,, client @option{--substitute-urls}
option}).
Substitute URLs can be either HTTP or HTTPS.
HTTPS is recommended because communications are encrypted; conversely,
using HTTP makes all communications visible to an eavesdropper, who
could use the information gathered to determine, for instance, whether
your system has unpatched security vulnerabilities.
Substitutes from the official build farm are enabled by default when
using the Guix System Distribution (@pxref{GNU Distribution}). However,
they are disabled by default when using Guix on a foreign distribution,
unless you have explicitly enabled them via one of the recommended
installation steps (@pxref{Installation}). The following paragraphs
describe how to enable or disable substitutes for the official build
farm; the same procedure can also be used to enable substitutes for any
other substitute server.
@node Substitute Server Authorization
@subsection Substitute Server Authorization
@cindex substitutes, authorization thereof
Ludovic Courtès
committed
@cindex access control list (ACL), for substitutes
@cindex ACL (access control list), for substitutes
To allow Guix to download substitutes from @code{@value{SUBSTITUTE-SERVER}} or a
mirror thereof, you
must add its public key to the access control list (ACL) of archive
imports, using the @command{guix archive} command (@pxref{Invoking guix
archive}). Doing so implies that you trust @code{@value{SUBSTITUTE-SERVER}} to not
be compromised and to serve genuine substitutes.
The public key for @code{@value{SUBSTITUTE-SERVER}} is installed along with Guix, in
@code{@var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub}, where @var{prefix} is
the installation prefix of Guix. If you installed Guix from source,
make sure you checked the GPG signature of
@file{guix-@value{VERSION}.tar.gz}, which contains this public key file.
Then, you can run something like this:
@example
# guix archive --authorize < @var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub
Similarly, the @file{hydra.gnu.org.pub} file contains the public key
of an independent build farm also run by the project, reachable at
@indicateurl{https://mirror.hydra.gnu.org}.
Once this is in place, the output of a command like @code{guix build}
should change from something like:
@example
$ 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
@dots{}
@end example
@noindent
to something like:
@example
$ guix build emacs --dry-run
/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
@dots{}
@end example
@noindent
This indicates that substitutes from @code{@value{SUBSTITUTE-SERVER}} are usable and
will be downloaded, when possible, for future builds.
@cindex substitutes, how to disable
The substitute mechanism can be disabled globally by running
@code{guix-daemon} with @code{--no-substitutes} (@pxref{Invoking
guix-daemon}). It can also be disabled temporarily by passing the
@code{--no-substitutes} option to @command{guix package}, @command{guix
build}, and other command-line tools.
@node Substitute Authentication
@subsection Substitute Authentication
@cindex digital signatures
Ludovic Courtès
committed
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
Guix detects and raises an error when attempting to use a substitute
that has been tampered with. Likewise, it ignores substitutes that are
not signed, or that are not signed by one of the keys listed in the ACL.
There is one exception though: if an unauthorized server provides
substitutes that are @emph{bit-for-bit identical} to those provided by
an authorized server, then the unauthorized server becomes eligible for
downloads. For example, assume we have chosen two substitute servers
with this option:
@example
--substitute-urls="https://a.example.org https://b.example.org"
@end example
@noindent
@cindex reproducible builds
If the ACL contains only the key for @code{b.example.org}, and if
@code{a.example.org} happens to serve the @emph{exact same} substitutes,
then Guix will download substitutes from @code{a.example.org} because it
comes first in the list and can be considered a mirror of
@code{b.example.org}. In practice, independent build machines usually
produce the same binaries, thanks to bit-reproducible builds (see
below).
When using HTTPS, the server's X.509 certificate is @emph{not} validated
(in other words, the server is not authenticated), contrary to what
HTTPS clients such as Web browsers usually do. This is because Guix
authenticates substitute information itself, as explained above, which
is what we care about (whereas X.509 certificates are about
authenticating bindings between domain names and public keys.)
@node Proxy Settings
@subsection Proxy Settings
@vindex http_proxy
Substitutes are downloaded over HTTP or HTTPS.
The @code{http_proxy} environment
variable can be set in the environment of @command{guix-daemon} and is
honored for downloads of substitutes. Note that the value of
@code{http_proxy} in the environment where @command{guix build},
@command{guix package}, and other client commands are run has
@emph{absolutely no effect}.
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
@node Substitution Failure
@subsection Substitution Failure
Even when a substitute for a derivation is available, sometimes the
substitution attempt will fail. This can happen for a variety of
reasons: the substitute server might be offline, the substitute may
recently have been deleted, the connection might have been interrupted,
etc.
When substitutes are enabled and a substitute for a derivation is
available, but the substitution attempt fails, Guix will attempt to
build the derivation locally depending on whether or not
@code{--fallback} was given (@pxref{fallback-option,, common build
option @code{--fallback}}). Specifically, if @code{--fallback} was
omitted, then no local build will be performed, and the derivation is
considered to have failed. However, if @code{--fallback} was given,
then Guix will attempt to build the derivation locally, and the success
or failure of the derivation depends on the success or failure of the
local build. Note that when substitutes are disabled or no substitute
is available for the derivation in question, a local build will
@emph{always} be performed, regardless of whether or not
@code{--fallback} was given.
To get an idea of how many substitutes are available right now, you can
try running the @command{guix weather} command (@pxref{Invoking guix
weather}). This command provides statistics on the substitutes provided
by a server.
@node On Trusting Binaries
@subsection On Trusting Binaries
@cindex trust, of pre-built binaries
Today, each individual's control over their own computing is at the
mercy of institutions, corporations, and groups with enough power and
determination to subvert the computing infrastructure and exploit its
weaknesses. While using @code{@value{SUBSTITUTE-SERVER}} substitutes can be
convenient, we encourage users to also build on their own, or even run
their own build farm, such that @code{@value{SUBSTITUTE-SERVER}} is less of an
interesting target. One way to help is by publishing the software you
build using @command{guix publish} so that others have one more choice
of server to download substitutes from (@pxref{Invoking guix publish}).
Guix has the foundations to maximize build reproducibility
(@pxref{Features}). In most cases, independent builds of a given
package or derivation should yield bit-identical results. Thus, through
a diverse set of independent package builds, we can strengthen the
integrity of our systems. The @command{guix challenge} command aims to
help users assess substitute servers, and to assist developers in
finding out about non-deterministic package builds (@pxref{Invoking guix
challenge}). Similarly, the @option{--check} option of @command{guix
build} allows users to check whether previously-installed substitutes
are genuine by rebuilding them locally (@pxref{build-check,
@command{guix build --check}}).
In the future, we want Guix to have support to publish and retrieve
binaries to/from other users, in a peer-to-peer fashion. If you would
like to discuss this project, join us on @email{guix-devel@@gnu.org}.
@node Packages with Multiple Outputs
@section Packages with Multiple Outputs
@cindex multiple-output packages
@cindex package outputs
Often, packages defined in Guix have a single @dfn{output}---i.e., the
source package leads to exactly one directory in the store. When running
@command{guix package -i glibc}, one installs the default output of the
GNU libc package; the default output is called @code{out}, but its name
can be omitted as shown in this command. In this particular case, the
default output of @code{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 @code{doc}. To install the main GLib output,
which contains everything but the documentation, one would run:
@example
guix package -i glib
@end example
The command to install its documentation is:
@example
guix package -i glib:doc
@end example
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 @command{guix size} command
can help find out about such situations (@pxref{Invoking guix size}).
@command{guix graph} can also be helpful (@pxref{Invoking guix graph}).
There are several such multiple-output packages in the GNU distribution.
Other conventional output names include @code{lib} for libraries and
possibly header files, @code{bin} for stand-alone programs, and
@code{debug} for debugging information (@pxref{Installing Debugging
Files}). The outputs of a packages are listed in the third column of
the output of @command{guix package --list-available} (@pxref{Invoking
guix package}).
@node Invoking guix gc
@section Invoking @command{guix gc}
Packages that are installed, but not used, may be @dfn{garbage-collected}.
The @command{guix gc} command allows users to explicitly run the garbage
collector to reclaim space from the @file{/gnu/store} directory. It is
the @emph{only} way to remove files from @file{/gnu/store}---removing
files or directories manually may break it beyond repair!
@cindex GC roots
@cindex garbage collector roots
The garbage collector has a set of known @dfn{roots}: any file under
@file{/gnu/store} reachable from a root is considered @dfn{live} and
cannot be deleted; any other file is considered @dfn{dead} and may be
deleted. The set of garbage collector roots (``GC roots'' for short)
includes default user profiles; by default, the symlinks under
@file{/var/guix/gcroots} represent these GC roots. New GC roots can be
added with @command{guix build --root}, for example (@pxref{Invoking
guix build}).
Prior to running @code{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 @code{guix package --delete-generations}
(@pxref{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@tie{}GB are available on your disk, simply run:
@example
guix gc -F 5G
@end example
It is perfectly safe to run as a non-interactive periodic job
(@pxref{Scheduled Job Execution}, for how to set up such a job on
GuixSD). Running @command{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 @command{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 @code{--delete} option), to print garbage-collector
information, or for more advanced queries. The garbage collection
options are as follows:
@table @code
@item --collect-garbage[=@var{min}]
@itemx -C [@var{min}]
Collect garbage---i.e., unreachable @file{/gnu/store} files and
sub-directories. This is the default operation when no option is
specified.
When @var{min} is given, stop once @var{min} bytes have been collected.
@var{min} may be a number of bytes, or it may include a unit as a
suffix, such as @code{MiB} for mebibytes and @code{GB} for gigabytes
(@pxref{Block size, size specifications,, coreutils, GNU Coreutils}).
When @var{min} is omitted, collect all the garbage.
@item --free-space=@var{free}
@itemx -F @var{free}
Collect garbage until @var{free} space is available under
@file{/gnu/store}, if possible; @var{free} denotes storage space, such
as @code{500MiB}, as described above.
When @var{free} or more is already available in @file{/gnu/store}, do
nothing and exit immediately.
@item --delete
@itemx -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.
@item --list-failures
List store items corresponding to cached build failures.
This prints nothing unless the daemon was started with
@option{--cache-failures} (@pxref{Invoking guix-daemon,
@option{--cache-failures}}).
@item --clear-failures
Remove the specified store items from the failed-build cache.
Again, this option only makes sense when the daemon is started with
@option{--cache-failures}. Otherwise, it does nothing.
@item --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.
@item --list-live
Show the list of live store files and directories.
@end table
In addition, the references among existing store files can be queried:
@table @code
@item --references
@itemx --referrers
List the references (respectively, the referrers) of store files given
as arguments.
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
@dfn{transitive closure} of the store files.
@xref{Invoking guix size}, for a tool to profile the size of the closure
of an element. @xref{Invoking guix graph}, for a tool to visualize
@item --derivers
@cindex derivation
Return the derivation(s) leading to the given store items
(@pxref{Derivations}).
For example, this command:
@example
guix gc --derivers `guix package -I ^emacs$ | cut -f4`
@end example
@noindent
returns the @file{.drv} file(s) leading to the @code{emacs} package
installed in your profile.
Note that there may be zero matching @file{.drv} files, for instance
because these files have been garbage-collected. There can also be more
than one matching @file{.drv} due to fixed-output derivations.
Lastly, the following options allow you to check the integrity of the
store and to control disk usage.
@table @option
@item --verify[=@var{options}]
@cindex integrity, of the store
@cindex integrity checking
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 @file{/gnu/store}.
When provided, @var{options} must be a comma-separated list containing one
or more of @code{contents} and @code{repair}.
When passing @option{--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 @emph{all the files in the store}, this command can take a
long time, especially on systems with a slow disk drive.
@cindex repairing the store
Using @option{--verify=repair} or @option{--verify=contents,repair}
causes the daemon to try to repair corrupt store items by fetching
substitutes for them (@pxref{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 @command{guix build --repair}
(@pxref{Invoking guix build}).
@item --optimize
@cindex deduplication
Optimize the store by hard-linking identical files---this is
@dfn{deduplication}.
The daemon performs deduplication after each successful build or archive
import, unless it was started with @code{--disable-deduplication}
(@pxref{Invoking guix-daemon, @code{--disable-deduplication}}). Thus,
this option is primarily useful when the daemon was running with
@code{--disable-deduplication}.
@end table
@node Invoking guix pull
@section Invoking @command{guix pull}
@cindex @command{guix pull}
@cindex 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 @command{guix
pull}: the command downloads the latest Guix source code and package
descriptions, and deploys it. Source code is downloaded from a
@uref{https://git-scm.com, Git} repository, by default the official
GNU@tie{}Guix repository, though this can be customized.
On completion, @command{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 @command{guix} sub-commands added by the update also
become available.
Any user can update their Guix copy using @command{guix pull}, and the
effect is limited to the user who run @command{guix pull}. For
instance, when user @code{root} runs @command{guix pull}, this has no
effect on the version of Guix that user @code{alice} sees, and vice
versa.
The result of running @command{guix pull} is a @dfn{profile} available
under @file{~/.config/guix/current} containing the latest Guix. Thus,
make sure to add it to the beginning of your search path so that you use
the latest version, and similarly for the Info manual
(@pxref{Documentation}):
@example
export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
@end example
The @code{--list-generations} or @code{-l} option lists past generations
produced by @command{guix pull}, along with details about their provenance:
@example
$ 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
2 new packages: keepalived, libnfnetlink
6 packages upgraded: emacs-nix-mode@@2.0.4,
guile2.0-guix@@0.14.0-12.77a1aac, guix@@0.14.0-12.77a1aac,
heimdal@@7.5.0, milkytracker@@1.02.00, nix@@2.0.4
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
28 new packages: emacs-helm-ls-git, emacs-helm-mu, @dots{}
69 packages upgraded: borg@@1.1.6, cheese@@3.28.0, @dots{}
@ref{Invoking guix describe, @command{guix describe}}, for other ways to
describe the current status of Guix.
This @code{~/.config/guix/current} profile works like any other profile
created by @command{guix package} (@pxref{Invoking guix package}). That
is, you can list generations, roll back to the previous
generation---i.e., the previous Guix---and so on:
@example
$ 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 @command{guix pull} command is usually invoked with no arguments,
but it supports the following options:
@table @code
@itemx --commit=@var{commit}
@itemx --branch=@var{branch}
Download code from the specified @var{url}, at the given @var{commit} (a valid
Git commit ID represented as a hexadecimal string), or @var{branch}.
@cindex @file{channels.scm}, configuration file
@cindex configuration file for channels
These options are provided for convenience, but you can also specify your
configuration in the @file{~/.config/guix/channels.scm} file or using the
@option{--channels} option (see below).
@item --channels=@var{file}
@itemx -C @var{file}
Read the list of channels from @var{file} instead of
@file{~/.config/guix/channels.scm}. @var{file} must contain Scheme code that
evaluates to a list of channel objects. @xref{Channels}, for more
information.
@item --list-generations[=@var{pattern}]
@itemx -l [@var{pattern}]
List all the generations of @file{~/.config/guix/current} or, if @var{pattern}
is provided, the subset of generations that match @var{pattern}.
The syntax of @var{pattern} is the same as with @code{guix package
--list-generations} (@pxref{Invoking guix package}).
@ref{Invoking guix describe}, for a way to display information about the
current generation only.
@item --profile=@var{profile}
@itemx -p @var{profile}
Use @var{profile} instead of @file{~/.config/guix/current}.
@item --dry-run
@itemx -n
Show which channel commit(s) would be used and what would be built or
substituted but do not actually do it.
@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of
the system type of the build host.
@item --verbose
Produce verbose output, writing build logs to the standard error output.
@item --bootstrap
Use the bootstrap Guile to build the latest Guix. This option is only
useful to Guix developers.
@end table
The @dfn{channel} mechanism allows you to instruct @command{guix pull} which
repository and branch to pull from, as well as @emph{additional} repositories
containing package modules that should be deployed. @xref{Channels}, for more
information.
In addition, @command{guix pull} supports all the common build options
(@pxref{Common Build Options}).
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
@node Channels
@section Channels
@cindex channels
@cindex @file{channels.scm}, configuration file
@cindex configuration file for channels
@cindex @command{guix pull}, configuration file
@cindex configuration of @command{guix pull}
Guix and its package collection are updated by running @command{guix pull}
(@pxref{Invoking guix pull}). By default @command{guix pull} downloads and
deploys Guix itself from the official GNU@tie{}Guix repository. This can be
customized by defining @dfn{channels} in the
@file{~/.config/guix/channels.scm} file. A channel specifies a URL and branch
of a Git repository to be deployed, and @command{guix pull} can be instructed
to pull from one or more channels. In other words, channels can be used to
@emph{customize} and to @emph{extend} Guix, as we will see below.
@subsection Using a Custom Guix Channel
The channel called @code{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 your own copy of the Guix repository at
@code{example.org}, and specifically the @code{super-hacks} branch, you can
write in @code{~/.config/guix/channels.scm} this specification:
@lisp
;; Tell 'guix pull' to use my own repo.
(list (channel
(name 'guix)
(url "https://example.org/my-guix.git")
(branch "super-hacks")))
@end lisp
@noindent
From there on, @command{guix pull} will fetch code from the @code{super-hacks}