diff options
Diffstat (limited to 'doc/guix.texi')
| -rw-r--r-- | doc/guix.texi | 901 |
1 files changed, 554 insertions, 347 deletions
diff --git a/doc/guix.texi b/doc/guix.texi index 80a1621b45..4c9a91b399 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -11,12 +11,13 @@ @copying Copyright @copyright{} 2012, 2013, 2014, 2015, 2016 Ludovic Courtès@* -Copyright @copyright{} 2013, 2014 Andreas Enge@* +Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@* Copyright @copyright{} 2013 Nikita Karetnikov@* Copyright @copyright{} 2015 Mathieu Lirzin@* Copyright @copyright{} 2014 Pierre-Antoine Rault@* Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@* Copyright @copyright{} 2015, 2016 Leo Famulari +Copyright @copyright{} 2016 Ben Woodcroft Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or @@ -247,7 +248,7 @@ 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 system's environment in +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 @dfn{containers}), where only their @@ -256,13 +257,13 @@ explicit inputs are visible. @cindex store The result of package build functions is @dfn{cached} in the file system, in a special directory called @dfn{the store} (@pxref{The -Store}). Each package is installed in a directory of its own, in the +Store}). Each package is installed in a directory of its own in the store---by default under @file{/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 of Guix's salient features: support for -transactional package upgrade and rollback, per-user installation, and +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 (@pxref{Features}). Guix has a command-line interface, which allows users to build, install, @@ -327,7 +328,7 @@ $ wget ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{system}.tar $ gpg --verify guix-binary-@value{VERSION}.@var{system}.tar.xz.sig @end example -If that command fails because you don't have the required public key, +If that command fails because you do not have the required public key, then run this command to import it: @example @@ -377,19 +378,29 @@ Create the group and user accounts for build users as explained below (@pxref{Build Environment Setup}). @item -Run the daemon: +Run the daemon, and set it to automatically start on boot. + +If your host distro uses the systemd init system, this can be achieved +with these commands: @example -# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild +# cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \ + /etc/systemd/system/ +# systemctl start guix-daemon && systemctl enable guix-daemon @end example -On hosts using the systemd init system, drop -@file{~root/.guix-profile/lib/systemd/system/guix-daemon.service} in -@file{/etc/systemd/system}. +If your host distro uses the Upstart init system: + +@example +# cp ~root/.guix-profile/lib/upstart/system/guix-daemon.conf /etc/init/ +# start guix-daemon +@end example -Likewise, on hosts using the Upstart init system, drop -@file{~root/.guix-profile/lib/upstart/system/guix-daemon.conf} in -@file{/etc/init}. +Otherwise, you can still start the daemon manually with: + +@example +# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild +@end example @item Make the @command{guix} command available to other users on the machine, @@ -425,16 +436,25 @@ authorize them: @end example @end enumerate -And that's it! For additional tips and tricks, @pxref{Application -Setup}. +This completes root-level install of Guix. Each user will need to +perform additional steps to make their Guix envionment ready for use, +@pxref{Application Setup}. -The @code{guix} package must remain available in @code{root}'s -profile, or it would become subject to garbage collection---in which -case you would find yourself badly handicapped by the lack of the -@command{guix} command. +You can confirm that Guix is working by installing a sample package into +the root profile: -The tarball in question can be (re)produced and verified simply by -running the following command in the Guix source tree: +@example +# guix package -i hello +@end example + +The @code{guix} package must remain available in @code{root}'s profile, +or it would become subject to garbage collection---in which case you +would find yourself badly handicapped by the lack of the @command{guix} +command. In other words, do not remove @code{guix} by running +@code{guix package -r guix}. + +The binary installation tarball can be (re)produced and verified simply +by running the following command in the Guix source tree: @example make guix-binary.@var{system}.tar.xz @@ -546,7 +566,7 @@ goes through the daemon. For instance, command-line tools such as daemon (@i{via} remote procedure calls) to instruct it what to do. The following sections explain how to prepare the build daemon's -environment. Also @ref{Substitutes}, for information on how to allow +environment. See also @ref{Substitutes}, for information on how to allow the daemon to download pre-built binaries. @menu @@ -625,7 +645,7 @@ that appear in the chroot's @code{/dev} is fixed, most of these files can only be created if the host has them.}; @item -the @code{/proc} directory; it only shows the container's processes +the @code{/proc} directory; it only shows the processes of the container since a separate PID name space is used; @item @@ -645,7 +665,7 @@ a writable @file{/tmp} directory. You can influence the directory where the daemon stores build trees @i{via} the @code{TMPDIR} environment variable. However, the build tree -within the chroot is always @file{/tmp/guix-build-@var{name}.drv-0}, +within the chroot is always called @file{/tmp/guix-build-@var{name}.drv-0}, where @var{name} is the derivation name---e.g., @code{coreutils-8.24}. This way, the value of @code{TMPDIR} does not leak inside build environments, which avoids discrepancies in cases where build processes @@ -674,9 +694,9 @@ When desired, the build daemon can @dfn{offload} derivation builds to other machines running Guix, using the @code{offload} @dfn{build hook}. When that feature is enabled, a list of user-specified build machines is read from -@file{/etc/guix/machines.scm}; anytime a build is requested, for +@file{/etc/guix/machines.scm}; every time a build is requested, for instance via @code{guix build}, the daemon attempts to offload it to one -of the machines that satisfies the derivation's constraints, in +of the machines that satisfy the constraints of the derivation, in particular its system type---e.g., @file{x86_64-linux}. Missing prerequisites for the build are copied over SSH to the target machine, which then proceeds with the build; upon success the output(s) of the @@ -715,16 +735,16 @@ Avahi in Guile Scheme Programs}). The @code{build-machine} data type is detailed below. @deftp {Data Type} build-machine -This data type represents build machines the daemon may offload builds -to. The important fields are: +This data type represents build machines to which the daemon may offload +builds. The important fields are: @table @code @item name -The remote machine's host name. +The host name of the remote machine. @item system -The remote machine's system type---e.g., @code{"x86_64-linux"}. +The system type of the remote machine---e.g., @code{"x86_64-linux"}. @item user The user account to use when connecting to the remote machine over SSH. @@ -738,7 +758,7 @@ A number of optional fields may be specified: @table @code @item port -Port number of the machine's SSH server (default: 22). +Port number of SSH server on the machine (default: 22). @item private-key The SSH private key file to use when connecting to the machine. @@ -774,7 +794,7 @@ this is the case by running: lsh build-machine guile -c "'(use-modules (guix config))'" @end example -There's one last thing to do once @file{machines.scm} is in place. As +There is one last thing to do once @file{machines.scm} is in place. As explained above, when offloading, files are transferred back and forth between the machine stores. For this to work, you first need to generate a key pair on each machine to allow the daemon to export signed @@ -1022,8 +1042,8 @@ get everything in place. Here are some of them. @cindex locales, when not on GuixSD @vindex LOCPATH @vindex GUIX_LOCPATH -Packages installed @i{via} Guix will not use the host system's locale -data. Instead, you must first install one of the locale packages +Packages installed @i{via} Guix will not use the locale data of the +host system. Instead, you must first install one of the locale packages available with Guix and then define the @code{GUIX_LOCPATH} environment variable: @@ -1034,7 +1054,7 @@ $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale Note that the @code{glibc-locales} package contains data for all the locales supported by the GNU@tie{}libc and weighs in at around -110@tie{}MiB. Alternately, the @code{glibc-utf8-locales} is smaller but +110@tie{}MiB. Alternatively, the @code{glibc-utf8-locales} is smaller but limited to a few UTF-8 locales. The @code{GUIX_LOCPATH} variable plays a role similar to @code{LOCPATH} @@ -1043,9 +1063,9 @@ Manual}). There are two important differences though: @enumerate @item -@code{GUIX_LOCPATH} is honored only by Guix's libc, and not by the libc +@code{GUIX_LOCPATH} is honored only by the libc in Guix, and not by the libc provided by foreign distros. Thus, using @code{GUIX_LOCPATH} allows you -to make sure the foreign distro's programs will not end up loading +to make sure the programs of the foreign distro will not end up loading incompatible locale data. @item @@ -1062,10 +1082,10 @@ versions may be incompatible. @subsection X11 Fonts The majority of graphical applications use Fontconfig to locate and -load fonts and perform X11-client-side rendering. Guix's -@code{fontconfig} package looks for fonts in @file{$HOME/.guix-profile} +load fonts and perform X11-client-side rendering. The @code{fontconfig} +package in Guix looks for fonts in @file{$HOME/.guix-profile} by default. Thus, to allow graphical applications installed with Guix -to display fonts, you will have to install fonts with Guix as well. +to display fonts, you have to install fonts with Guix as well. Essential font packages include @code{gs-fonts}, @code{font-dejavu}, and @code{font-gnu-freefont-ttf}. @@ -1094,9 +1114,9 @@ the Emacs package system organizes the file structure (@pxref{Package Files,,, emacs, The GNU Emacs Manual}). By default, Emacs (installed with Guix) ``knows'' where these packages -are placed, so you don't need to perform any configuration. If, for +are placed, so you do not need to perform any configuration. If, for some reason, you want to avoid auto-loading Emacs packages installed -with Guix, you can do it by running Emacs with @code{--no-site-file} +with Guix, you can do so by running Emacs with @code{--no-site-file} option (@pxref{Init File,,, emacs, The GNU Emacs Manual}). @c TODO What else? @@ -1107,7 +1127,7 @@ option (@pxref{Init File,,, emacs, The GNU Emacs Manual}). The purpose of GNU Guix is to allow users to easily install, upgrade, and remove software packages, without having to know about their build -procedure or dependencies. Guix also goes beyond this obvious set of +procedures or dependencies. Guix also goes beyond this obvious set of features. This chapter describes the main features of Guix, as well as the package @@ -1149,7 +1169,7 @@ simply continues to point to coexist on the same system without any interference. The @command{guix package} command is the central tool to manage -packages (@pxref{Invoking guix package}). It operates on those per-user +packages (@pxref{Invoking guix package}). It operates on the per-user profiles, and can be used @emph{with normal user privileges}. The command provides the obvious install, remove, and upgrade @@ -1166,8 +1186,8 @@ of their profile, which was known to work well. Similarly, the global system configuration is subject to transactional upgrades and roll-back (@pxref{Using the Configuration System}). -All those packages in the package store may be @emph{garbage-collected}. -Guix can determine which packages are still referenced by the user +All packages in the package store may be @emph{garbage-collected}. +Guix can determine which packages are still referenced by user profiles, and remove those that are provably no longer referenced (@pxref{Invoking guix gc}). Users may also explicitly remove old generations of their profile so that the packages they refer to can be @@ -1197,8 +1217,8 @@ otherwise, it builds the package from source, locally Control over the build environment is a feature that is also useful for developers. The @command{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 package's dependencies -in their profile (@pxref{Invoking guix environment}). +package, without having to manually install the dependencies of the +package into their profile (@pxref{Invoking guix environment}). @node Invoking guix package @section Invoking @command{guix package} @@ -1289,7 +1309,7 @@ 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 independently. +also been explicitly installed by the user. Besides, packages sometimes rely on the definition of environment variables for their search paths (see explanation of @@ -1327,7 +1347,7 @@ As an example, @var{file} might contain a definition like this @end example Developers may find it useful to include such a @file{package.scm} file -in the root of their project's source tree that can be used to test +in the root of their project source tree that can be used to test development snapshots and create reproducible development environments (@pxref{Invoking guix environment}). @@ -1398,11 +1418,11 @@ before any other actions. 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 meta-data. +generation}, which contains no files apart from its own metadata. -Installing, removing, or upgrading packages from a generation that has -been rolled back to overwrites previous future generations. Thus, the -history of a profile's generations is always linear. +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} @@ -1465,8 +1485,8 @@ variable, even though, taken individually, neither @file{foo} nor Use @var{profile} instead of the user's default profile. @item --verbose -Produce verbose output. In particular, emit the environment's build log -on the standard error port. +Produce verbose output. In particular, emit the build log of the +environment on the standard error port. @item --bootstrap Use the bootstrap Guile to build the profile. This option is only @@ -1474,7 +1494,7 @@ useful to distribution developers. @end table -In addition to these actions @command{guix package} supports the +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: @@ -1484,7 +1504,7 @@ availability of packages: @itemx -s @var{regexp} @cindex searching for packages List the available packages whose name, synopsis, or description matches -@var{regexp}. Print all the meta-data of matching packages in +@var{regexp}. Print all the metadata of matching packages in @code{recutils} format (@pxref{Top, GNU recutils databases,, recutils, GNU recutils manual}). @@ -1610,7 +1630,7 @@ 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 -a range must be lesser than its end. +a range must be smaller than its end. It is also possible to omit the endpoint. For example, @code{--list-generations=2..}, returns all generations starting from the @@ -1636,17 +1656,17 @@ 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 roll-back to them. +Note that deleting generations prevents rolling back to them. Consequently, this command must be used with care. @end table Finally, since @command{guix package} may actually start build processes, it supports all the common build options (@pxref{Common Build -Options}). It also support package transformation options, such as +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 transformation across upgrades, you should define your own +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}). @@ -1781,7 +1801,7 @@ like to discuss this project, join us on @email{guix-devel@@gnu.org}. @cindex package outputs Often, packages defined in Guix have a single @dfn{output}---i.e., the -source package leads exactly one directory in the store. When running +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 @@ -1808,7 +1828,7 @@ guix package -i glib:doc @end example Some packages install programs with different ``dependency footprints''. -For instance, the WordNet package install both command-line tools and +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 @@ -1830,7 +1850,7 @@ guix package}). @section Invoking @command{guix gc} @cindex garbage collector -Packages that are installed but not used may be @dfn{garbage-collected}. +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 @@ -1914,8 +1934,8 @@ 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 an -element's closure. @xref{Invoking guix graph}, for a tool to visualize +@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 the graph of references. @end table @@ -1931,13 +1951,13 @@ store and to control disk usage. Verify the integrity of the store. By default, make sure that all the store items marked as valid in the -daemon's database actually exist in @file{/gnu/store}. +database of the daemon actually exist in @file{/gnu/store}. -When provided, @var{options} must a comma-separated list containing one +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 will compute the -content hash of each store item and compare it against its hash in the +When passing @option{--verify=contents}, the daemon computse 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. @@ -1975,9 +1995,15 @@ 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@footnote{Under the hood, @command{guix pull} updates -the @file{~/.config/guix/latest} symbolic link to point to the latest -Guix, and the @command{guix} command loads code from there.}. +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@footnote{Under the hood, @command{guix pull} updates the +@file{~/.config/guix/latest} symbolic link to point to the latest Guix, +and the @command{guix} command loads code from there.}. The @command{guix pull} command is usually invoked with no arguments, but it supports the following options: @@ -2004,8 +2030,30 @@ useful to Guix developers. The @command{guix archive} command allows users to @dfn{export} files from the store into a single archive, and to later @dfn{import} them. In particular, it allows store files to be transferred from one machine -to another machine's store. For example, to transfer the @code{emacs} -package to a machine connected over SSH, one would run: +to the store on another machine. + +To export store files as an archive to standard output, run: + +@example +guix archive --export @var{options} @var{specifications}... +@end example + +@var{specifications} may be either store file names or package +specifications, as for @command{guix package} (@pxref{Invoking guix +package}). For instance, the following command creates an archive +containing the @code{gui} output of the @code{git} package and the main +output of @code{emacs}: + +@example +guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar +@end example + +If the specified packages are not built yet, @command{guix archive} +automatically builds them. The build process may be controlled with the +common build options (@pxref{Common Build Options}). + +To transfer the @code{emacs} package to a machine connected over SSH, +one would run: @example guix archive --export -r emacs | ssh the-machine guix archive --import @@ -2023,14 +2071,14 @@ guix archive --export -r $(readlink -f ~/.guix-profile) | \ @noindent However, note that, in both examples, all of @code{emacs} and the profile as well as all of their dependencies are transferred (due to -@code{-r}), regardless of what is already available in the target -machine's store. The @code{--missing} option can help figure out which -items are missing from the target's store. +@code{-r}), regardless of what is already available in the store on the +target machine. The @code{--missing} option can help figure out which +items are missing from the target store. Archives are stored in the ``Nix archive'' or ``Nar'' format, which is comparable in spirit to `tar', but with a few noteworthy differences that make it more appropriate for our purposes. First, rather than -recording all Unix meta-data for each file, the Nar format only mentions +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 @@ -2073,7 +2121,7 @@ the store. @item --generate-key[=@var{parameters}] @cindex signing, archives -Generate a new key pair for the daemons. This is a prerequisite before +Generate a new key pair for the daemon. This is a prerequisite before archives can be exported with @code{--export}. Note that this operation usually takes time, because it needs to gather enough entropy to generate the key pair. @@ -2083,7 +2131,7 @@ The generated key pair is typically stored under @file{/etc/guix}, in key, which must be kept secret.) When @var{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. -Alternately, @var{parameters} can specify +Alternatively, @var{parameters} can specify @code{genkey} parameters suitable for Libgcrypt (@pxref{General public-key related Functions, @code{gcry_pk_genkey},, gcrypt, The Libgcrypt Reference Manual}). @@ -2127,26 +2175,6 @@ archive contents coming from possibly untrusted substitute servers. @end table -To export store files as an archive to the standard output, run: - -@example -guix archive --export @var{options} @var{specifications}... -@end example - -@var{specifications} may be either store file names or package -specifications, as for @command{guix package} (@pxref{Invoking guix -package}). For instance, the following command creates an archive -containing the @code{gui} output of the @code{git} package and the main -output of @code{emacs}: - -@example -guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar -@end example - -If the specified packages are not built yet, @command{guix archive} -automatically builds them. The build process may be controlled with the -common build options (@pxref{Common Build Options}). - @c ********************************************************************* @include emacs.texi @@ -2226,8 +2254,8 @@ package looks like this: @noindent Without being a Scheme expert, the reader may have guessed the meaning -of the various fields here. This expression binds variable @code{hello} -to a @code{<package>} object, which is essentially a record +of the various fields here. This expression binds the variable +@code{hello} to a @code{<package>} object, which is essentially a record (@pxref{SRFI-9, Scheme records,, guile, GNU Guile Reference Manual}). This package object can be inspected using procedures found in the @code{(guix packages)} module; for instance, @code{(package-name hello)} @@ -2237,7 +2265,7 @@ 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 @code{guix import} command (@pxref{Invoking guix import}). -In the example above, @var{hello} is defined into a module of its own, +In the example above, @var{hello} is defined in a module of its own, @code{(gnu packages hello)}. Technically, this is not strictly necessary, but it is convenient to do so: all the packages defined in modules under @code{(gnu packages @dots{})} are automatically known to @@ -2308,7 +2336,7 @@ more information on how to test package definitions, and @ref{Invoking guix lint}, for information on how to check a definition for style conformance. -Eventually, updating the package definition to a new upstream version +Finally, updating the package definition to a new upstream version can be partly automated by the @command{guix refresh} command (@pxref{Invoking guix refresh}). @@ -2388,7 +2416,7 @@ tuples, where each tuple has a label for the input (a string) as its first element, a package, origin, or derivation as its second element, and optionally the name of the output thereof that should be used, which defaults to @code{"out"} (@pxref{Packages with Multiple Outputs}, for -more on package outputs). For example, the list below specifies 3 +more on package outputs). For example, the list below specifies three inputs: @example @@ -2404,15 +2432,15 @@ dependencies listed in @code{inputs} are built for the @emph{target} architecture; conversely, dependencies listed in @code{native-inputs} are built for the architecture of the @emph{build} machine. -@code{native-inputs} is typically where you would list tools needed at -build time but not at run time, such as Autoconf, Automake, pkg-config, +@code{native-inputs} is typically used to list tools needed at +build time, but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or Bison. @command{guix lint} can report likely mistakes in this area (@pxref{Invoking guix lint}). @anchor{package-propagated-inputs} Lastly, @code{propagated-inputs} is similar to @code{inputs}, but the -specified packages will be force-installed alongside the package they -belong to (@pxref{package-cmd-propagated-inputs, @command{guix +specified packages will be automatically installed alongside the package +they belong to (@pxref{package-cmd-propagated-inputs, @command{guix package}}, for information on how @command{guix package} deals with propagated inputs.) @@ -2420,9 +2448,9 @@ For example this is necessary when a C/C++ library needs headers of another library to compile, or when a pkg-config file refers to another one @i{via} its @code{Requires} field. -Another example where @code{propagated-inputs} is useful is for -languages that lack a facility to record the run-time search path akin -to ELF's @code{RUNPATH}; this includes Guile, Python, Perl, GHC, and +Another example where @code{propagated-inputs} is useful is for languages +that lack a facility to record the run-time search path akin to the +@code{RUNPATH}of ELF files; this includes Guile, Python, Perl, GHC, and more. To ensure that libraries written in those languages can find library code they depend on at run time, run-time dependencies must be listed in @code{propagated-inputs} rather than @code{inputs}. @@ -2441,7 +2469,7 @@ A list of @code{search-path-specification} objects describing search-path environment variables honored by the package. @item @code{replacement} (default: @code{#f}) -This must either @code{#f} or a package object that will be used as a +This must be either @code{#f} or a package object that will be used as a @dfn{replacement} for this package. @xref{Security Updates, grafts}, for details. @@ -2452,7 +2480,8 @@ A one-line description of the package. A more elaborate description of the package. @item @code{license} -The license of the package; a value from @code{(guix licenses)}. +The license of the package; a value from @code{(guix licenses)}, +or a list of such values. @item @code{home-page} The URL to the home-page of the package, as a string. @@ -2465,7 +2494,7 @@ The list of systems supported by the package, as strings of the form The list of maintainers of the package, as @code{maintainer} objects. @item @code{location} (default: source location of the @code{package} form) -The source location of the package. It's useful to override this when +The source location of the package. It is useful to override this when inheriting from another package, in which case this field is not automatically corrected. @end table @@ -2489,13 +2518,13 @@ the @code{method} (see below). For example, when using the values are: a URL represented as a string, or a list thereof. @item @code{method} -A procedure that will handle the URI. +A procedure that handles the URI. Examples include: @table @asis @item @var{url-fetch} from @code{(guix download)} -download a file the HTTP, HTTPS, or FTP URL specified in the +download a file from the HTTP, HTTPS, or FTP URL specified in the @code{uri} field; @item @var{git-fetch} from @code{(guix git-download)} @@ -2519,7 +2548,7 @@ base-32 string. The file name under which the source code should be saved. When this is @code{#f}, a sensible default value will be used in most cases. In case the source is fetched from a URL, the file name from the URL will be -used. For version control checkouts, it's recommended to provide the +used. For version control checkouts, it is recommended to provide the file name explicitly because the default is not very descriptive. @item @code{patches} (default: @code{'()}) @@ -2559,7 +2588,7 @@ this is @code{#f}, a sensible default is used. @cindex build system Each package definition specifies a @dfn{build system} and arguments for that build system (@pxref{Defining Packages}). This @code{build-system} -field represents the build procedure of the package, as well implicit +field represents the build procedure of the package, as well as implicit dependencies of that build procedure. Build systems are @code{<build-system>} objects. The interface to @@ -2583,7 +2612,7 @@ evaluated in the @dfn{build stratum}---i.e., by a Guile process launched by the daemon (@pxref{Derivations}). The main build system is @var{gnu-build-system}, which implements the -standard build procedure for GNU packages and many other packages. It +standard build procedure for GNU and many other packages. It is provided by the @code{(guix build-system gnu)} module. @defvr {Scheme Variable} gnu-build-system @@ -2592,7 +2621,7 @@ thereof (@pxref{Configuration, configuration and makefile conventions,, standards, GNU Coding Standards}). @cindex build phases -In a nutshell, packages using it configured, built, and installed with +In a nutshell, packages using it are configured, built, and installed with the usual @code{./configure && make && make check && make install} command sequence. In practice, a few additional steps are often needed. All these steps are split up in separate @dfn{phases}, @@ -2648,7 +2677,7 @@ The list of phases used for a particular package can be changed with the @code{#:phases} parameter. For instance, passing: @example -#:phases (alist-delete 'configure %standard-phases) +#:phases (modify-phases %standard-phases (delete 'configure)) @end example means that all the phases described above will be used, except the @@ -2657,8 +2686,8 @@ means that all the phases described above will be used, except the In addition, this build system ensures that the ``standard'' environment for GNU packages is available. This includes tools such as GCC, libc, Coreutils, Bash, Make, Diffutils, grep, and sed (see the @code{(guix -build-system gnu)} module for a complete list.) We call these the -@dfn{implicit inputs} of a package, because package definitions don't +build-system gnu)} module for a complete list). We call these the +@dfn{implicit inputs} of a package, because package definitions do not have to mention them. @end defvr @@ -2694,8 +2723,8 @@ This build system adds the following two phases to the ones defined by @table @code @item glib-or-gtk-wrap -The phase @code{glib-or-gtk-wrap} ensures that programs found under -@file{bin/} are able to find GLib's ``schemas'' and +The phase @code{glib-or-gtk-wrap} ensures that programs in +@file{bin/} are able to find GLib ``schemas'' and @uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, GTK+ modules}. This is achieved by wrapping the programs in launch scripts that appropriately set the @code{XDG_DATA_DIRS} and @code{GTK_PATH} @@ -2709,9 +2738,9 @@ where wrapping would gratuitously add a dependency of that output on GLib and GTK+. @item glib-or-gtk-compile-schemas -The phase @code{glib-or-gtk-compile-schemas} makes sure that all GLib's +The phase @code{glib-or-gtk-compile-schemas} makes sure that all @uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html, -GSettings schemas} are compiled. Compilation is performed by the +GSettings schemas} of GLib are compiled. Compilation is performed by the @command{glib-compile-schemas} program. It is provided by the package @code{glib:bin} which is automatically imported by the build system. The @code{glib} package providing @command{glib-compile-schemas} can be @@ -2728,7 +2757,7 @@ packages, which consists in running @code{python setup.py build} and then @code{python setup.py install --prefix=/gnu/store/@dots{}}. For packages that install stand-alone Python programs under @code{bin/}, -it takes care of wrapping these programs so their @code{PYTHONPATH} +it takes care of wrapping these programs so that their @code{PYTHONPATH} environment variable points to all the Python libraries they depend on. Which Python package is used can be specified with the @code{#:python} @@ -2741,7 +2770,7 @@ implements the standard build procedure for Perl packages, which either consists in running @code{perl Build.PL --prefix=/gnu/store/@dots{}}, followed by @code{Build} and @code{Build install}; or in running @code{perl Makefile.PL PREFIX=/gnu/store/@dots{}}, followed by -@code{make} and @code{make install}; depending on which of +@code{make} and @code{make install}, depending on which of @code{Build.PL} or @code{Makefile.PL} is present in the package distribution. Preference is given to the former if both @code{Build.PL} and @code{Makefile.PL} exist in the package distribution. This @@ -2816,8 +2845,8 @@ parameter which defaults to @code{ghc}. @defvr {Scheme Variable} emacs-build-system This variable is exported by @code{(guix build-system emacs)}. It -implements an installation procedure similar to the one of Emacs' own -packaging system (@pxref{Packages,,, emacs, The GNU Emacs Manual}). +implements an installation procedure similar to the packaging system +of Emacs itself (@pxref{Packages,,, emacs, The GNU Emacs Manual}). It first creates the @code{@var{package}-autoloads.el} file, then it byte compiles all Emacs Lisp files. Differently from the Emacs @@ -2836,7 +2865,7 @@ and does not have a notion of build phases. This variable is exported by @code{(guix build-system trivial)}. This build system requires a @code{#:builder} argument. This argument -must be a Scheme expression that builds the package's output(s)---as +must be a Scheme expression that builds the package output(s)---as with @code{build-expression->derivation} (@pxref{Derivations, @code{build-expression->derivation}}). @end defvr @@ -2847,8 +2876,8 @@ with @code{build-expression->derivation} (@pxref{Derivations, @cindex store @cindex store paths -Conceptually, the @dfn{store} is where derivations that have been -successfully built are stored---by default, under @file{/gnu/store}. +Conceptually, the @dfn{store} is the place where derivations that have +been built successfully are stored---by default, @file{/gnu/store}. Sub-directories in the store are referred to as @dfn{store paths}. The store has an associated database that contains information such as the store paths referred to by each store path, and the list of @emph{valid} @@ -2856,8 +2885,8 @@ store paths---paths that result from a successful build. The store is always accessed by the daemon on behalf of its clients (@pxref{Invoking guix-daemon}). To manipulate the store, clients -connect to the daemon over a Unix-domain socket, send it requests, and -read the result---these are remote procedure calls, or RPCs. +connect to the daemon over a Unix-domain socket, send requests to it, +and read the result---these are remote procedure calls, or RPCs. The @code{(guix store)} module provides procedures to connect to the daemon, and to perform RPCs. These are described below. @@ -2866,7 +2895,7 @@ daemon, and to perform RPCs. These are described below. Connect to the daemon over the Unix-domain socket at @var{file}. When @var{reserve-space?} is true, instruct it to reserve a little bit of extra space on the file system so that the garbage collector can still -operate, should the disk become full. Return a server object. +operate should the disk become full. Return a server object. @var{file} defaults to @var{%default-socket-path}, which is the normal location given the options that were passed to @command{configure}. @@ -2885,7 +2914,14 @@ Procedures that make RPCs all take a server object as their first argument. @deffn {Scheme Procedure} valid-path? @var{server} @var{path} -Return @code{#t} when @var{path} is a valid store path. +@cindex invalid store items +Return @code{#t} when @var{path} designates a valid store item and +@code{#f} otherwise (an invalid item may exist on disk but still be +invalid, for instance because it is the result of an aborted or failed +build.) + +A @code{&nix-protocol-error} condition is raised if @var{path} is not +prefixed by the store directory (@file{/gnu/store}). @end deffn @deffn {Scheme Procedure} add-text-to-store @var{server} @var{name} @var{text} [@var{references}] @@ -3155,9 +3191,9 @@ So, to exit the monad and get the desired effect, one must use @result{} /gnu/store/...-sh-symlink @end example -Note that the @code{(guix monad-repl)} module extends Guile's REPL with +Note that the @code{(guix monad-repl)} module extends the Guile REPL with new ``meta-commands'' to make it easier to deal with monadic procedures: -@code{run-in-store}, and @code{enter-store-monad}. The former, is used +@code{run-in-store}, and @code{enter-store-monad}. The former is used to ``run'' a single monadic value through the store: @example @@ -3339,7 +3375,8 @@ monadic procedures: @deffn {Monadic Procedure} package-file @var{package} [@var{file}] @ [#:system (%current-system)] [#:target #f] @ - [#:output "out"] Return as a monadic + [#:output "out"] +Return as a monadic value in the absolute file name of @var{file} within the @var{output} directory of @var{package}. When @var{file} is omitted, return the name of the @var{output} directory of @var{package}. When @var{target} is @@ -3361,12 +3398,12 @@ Monadic version of @code{package-derivation} and @cindex build code quoting So we have ``derivations'', which represent a sequence of build actions to be performed to produce an item in the store (@pxref{Derivations}). -Those build actions are performed when asking the daemon to actually +These build actions are performed when asking the daemon to actually build the derivations; they are run by the daemon in a container (@pxref{Invoking guix-daemon}). @cindex strata of code -It should come as no surprise that we like to write those build actions +It should come as no surprise that we like to write these build actions in Scheme. When we do that, we end up with two @dfn{strata} of Scheme code@footnote{The term @dfn{stratum} in this context was coined by Manuel Serrano et al.@: in the context of their work on Hop. Oleg @@ -3380,19 +3417,19 @@ performs build actions, such as making directories, invoking To describe a derivation and its build actions, one typically needs to embed build code inside host code. It boils down to manipulating build -code as data, and Scheme's homoiconicity---code has a direct +code as data, and the homoiconicity of Scheme---code has a direct representation as data---comes in handy for that. But we need more than -Scheme's normal @code{quasiquote} mechanism to construct build +the normal @code{quasiquote} mechanism in Scheme to construct build expressions. The @code{(guix gexp)} module implements @dfn{G-expressions}, a form of S-expressions adapted to build expressions. G-expressions, or -@dfn{gexps}, consist essentially in three syntactic forms: @code{gexp}, +@dfn{gexps}, consist essentially of three syntactic forms: @code{gexp}, @code{ungexp}, and @code{ungexp-splicing} (or simply: @code{#~}, -@code{#$}, and @code{#$@@}), which are comparable respectively to -@code{quasiquote}, @code{unquote}, and @code{unquote-splicing} -(@pxref{Expression Syntax, @code{quasiquote},, guile, GNU Guile -Reference Manual}). However, there are major differences: +@code{#$}, and @code{#$@@}), which are comparable to +@code{quasiquote}, @code{unquote}, and @code{unquote-splicing}, +respectivel (@pxref{Expression Syntax, @code{quasiquote},, guile, +GNU Guile Reference Manual}). However, there are major differences: @itemize @item @@ -3415,9 +3452,9 @@ This mechanism is not limited to package and derivation objects: @dfn{compilers} able to ``lower'' other high-level objects to derivations or files in the store can be defined, such that these objects can also be inserted -into gexps. For example, a useful type of high-level object that can be +into gexps. For example, a useful type of high-level objects that can be inserted in a gexp is ``file-like objects'', which make it easy to -add files to the store and refer to them in +add files to the store and to refer to them in derivations and such (see @code{local-file} and @code{plain-file} below.) @@ -3444,8 +3481,8 @@ As one would expect, the @code{"/gnu/store/@dots{}-coreutils-8.22"} string is substituted to the reference to the @var{coreutils} package in the actual build code, and @var{coreutils} is automatically made an input to the derivation. Likewise, @code{#$output} (equivalent to @code{(ungexp -output)}) is replaced by a string containing the derivation's output -directory name. +output)}) is replaced by a string containing the directory name of the +output of the derivation. @cindex cross compilation In a cross-compilation context, it is useful to distinguish between @@ -3784,7 +3821,7 @@ The general syntax is: guix build @var{options} @var{package-or-derivation}@dots{} @end example -As an example, the following command builds the latest version of Emacs +As an example, the following command builds the latest versions of Emacs and of Guile, displays their build logs, and finally displays the resulting directories: @@ -3890,7 +3927,7 @@ stashing one of the build results with @code{guix archive --export}, then rebuilding, and finally comparing the two results. @item --no-build-hook -Do not attempt to offload builds @i{via} the daemon's ``build hook'' +Do not attempt to offload builds @i{via} the ``build hook'' of the daemon (@pxref{Daemon Offload Setup}). That is, always build things locally instead of offloading builds to remote machines. @@ -3953,7 +3990,7 @@ the parsed command-line options. @cindex package variants Another set of command-line options supported by @command{guix build} and also @command{guix package} are @dfn{package transformation -options}. These are options that allow you to define @dfn{package +options}. These are options that make it possible to define @dfn{package variants}---for instance, packages built from different source code. This is a convenient way to create customized packages on the fly without having to type in the definitions of package variants @@ -3966,11 +4003,11 @@ Use @var{source} as the source of the corresponding package. @var{source} must be a file name or a URL, as for @command{guix download} (@pxref{Invoking guix download}). -The ``corresponding package'' is taken to be one specified on the -command line whose name matches the base of @var{source}---e.g., if -@var{source} is @code{/src/guile-2.0.10.tar.gz}, the corresponding +The ``corresponding package'' is taken to be the one specified on the +command line the name of which matches the base of @var{source}---e.g., +if @var{source} is @code{/src/guile-2.0.10.tar.gz}, the corresponding package is @code{guile}. Likewise, the version string is inferred from -@var{source}; in the previous example, it's @code{2.0.10}. +@var{source}; in the previous example, it is @code{2.0.10}. This option allows users to try out versions of packages other than the one provided by the distribution. The example below downloads @@ -4001,7 +4038,7 @@ Replace dependency on @var{package} by a dependency on @var{replacement} must be a package specification such as @code{guile} or @code{guile@@1.8}. -For instance, the following command builds Guix but replaces its +For instance, the following command builds Guix, but replaces its dependency on the current stable version of Guile with a dependency on the development version of Guile, @code{guile-next}: @@ -4045,7 +4082,7 @@ For example, @var{expr} may be @code{(@@ (gnu packages guile) guile-1.8)}, which unambiguously designates this specific variant of version 1.8 of Guile. -Alternately, @var{expr} may be a G-expression, in which case it is used +Alternatively, @var{expr} may be a G-expression, in which case it is used as a build program passed to @code{gexp->derivation} (@pxref{G-Expressions}). @@ -4055,14 +4092,15 @@ monadic value, which is then passed through @code{run-with-store}. @item --source @itemx -S -Build the packages' source derivations, rather than the packages +Build the source derivations of the packages, rather than the packages themselves. For instance, @code{guix build -S gcc} returns something like -@file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, which is GCC's source tarball. +@file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, which is the GCC +source tarball. The returned source tarball is the result of applying any patches and -code snippets specified in the package's @code{origin} (@pxref{Defining +code snippets specified in the package @code{origin} (@pxref{Defining Packages}). @item --sources @@ -4079,8 +4117,8 @@ This value causes the @code{--sources} option to behave in the same way as the @code{--source} option. @item all -Build all packages' source derivations, including any source that might -be listed as @code{inputs}. This is the default value. +Build the source derivations of all packages, including any source that +might be listed as @code{inputs}. This is the default value. @example $ guix build --sources tzdata @@ -4090,8 +4128,8 @@ The following derivations will be built: @end example @item transitive -Build all packages' source derivations, as well as all source -derivations for packages' transitive inputs. This can be used e.g. to +Build the source derivations of all packages, as well of all transitive +inputs to the packages. This can be used e.g. to prefetch package source for later offline building. @example @@ -4111,7 +4149,7 @@ The following derivations will be built: @item --system=@var{system} @itemx -s @var{system} Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of -the host's system type. +the system type of the build host. An example use of this is on Linux-based systems, which can emulate different personalities. For instance, passing @@ -4132,9 +4170,9 @@ Rebuild @var{package-or-derivation}, which are already available in the store, and raise an error if the build results are not bit-for-bit identical. -This mechanism allows you to check whether previously-installed -substitutes are genuine (@pxref{Substitutes}), or whether a package's -build result is deterministic. @xref{Invoking guix challenge}, for more +This mechanism allows you to check whether previously installed +substitutes are genuine (@pxref{Substitutes}), or whether the build result +of a package is deterministic. @xref{Invoking guix challenge}, for more background information and tools. @item --no-grafts @@ -4154,7 +4192,7 @@ collector root. @item --log-file Return the build log file names or URLs for the given -@var{package-or-derivation}s, or raise an error if build logs are +@var{package-or-derivation}, or raise an error if build logs are missing. This works regardless of how packages or derivations are specified. For @@ -4171,8 +4209,8 @@ If a log is unavailable locally, and unless @code{--no-substitutes} is passed, the command looks for a corresponding log on one of the substitute servers (as specified with @code{--substitute-urls}.) -So for instance, let's say you want to see the build log of GDB on MIPS -but you're actually on an @code{x86_64} machine: +So for instance, imagine you want to see the build log of GDB on MIPS, +but you are actually on an @code{x86_64} machine: @example $ guix build --log-file gdb -s mips64el-linux @@ -4200,9 +4238,9 @@ launches the program specified in the @code{VISUAL} or in the @code{EDITOR} environment variable to edit the recipe of GCC@tie{}4.8.4 and that of Vim. -If you are using Emacs, note that the Emacs user interface provides +If you are using Emacs, note that the Emacs user interface provides the @kbd{M-x guix-edit} command and a similar functionality in the ``package -info'' and ``package list'' buffers created by @kbd{M-x +info'' and ``package list'' buffers created by the @kbd{M-x guix-search-by-name} and similar commands (@pxref{Emacs Commands}). @@ -4210,7 +4248,7 @@ guix-search-by-name} and similar commands (@pxref{Emacs Commands}). @section Invoking @command{guix download} When writing a package definition, developers typically need to download -the package's source tarball, compute its SHA256 hash, and write that +a source tarball, compute its SHA256 hash, and write that hash in the package definition (@pxref{Defining Packages}). The @command{guix download} tool helps with this task: it downloads a file from the given URI, adds it to the store, and prints both its file name @@ -4274,10 +4312,10 @@ in the definitions of packages. Compute the hash on @var{file} recursively. In this case, the hash is computed on an archive containing @var{file}, -including its children if it is a directory. Some of @var{file}'s -meta-data is part of the archive; for instance, when @var{file} is a +including its children if it is a directory. Some of the metadata of +@var{file} is part of the archive; for instance, when @var{file} is a regular file, the hash is different depending on whether @var{file} is -executable or not. Meta-data such as time stamps has no impact on the +executable or not. Metadata such as time stamps has no impact on the hash (@pxref{Invoking guix archive}). @c FIXME: Replace xref above with xref to an ``Archive'' section when @c it exists. @@ -4290,10 +4328,10 @@ hash (@pxref{Invoking guix archive}). @cindex importing packages @cindex package import @cindex package conversion -The @command{guix import} command is useful for people willing to add a -package to the distribution but who'd rather do as little work as -possible to get there---a legitimate demand. The command knows of a few -repositories from which it can ``import'' package meta-data. The result +The @command{guix import} command is useful for people who would like to +add a package to the distribution with as little work as +possible---a legitimate demand. The command knows of a few +repositories from which it can ``import'' package metadata. The result is a package definition, or a template thereof, in the format we know (@pxref{Defining Packages}). @@ -4304,17 +4342,17 @@ guix import @var{importer} @var{options}@dots{} @end example @var{importer} specifies the source from which to import package -meta-data, and @var{options} specifies a package identifier and other +metadata, and @var{options} specifies a package identifier and other options specific to @var{importer}. Currently, the available ``importers'' are: @table @code @item gnu -Import meta-data for the given GNU package. This provides a template +Import metadata for the given GNU package. This provides a template for the latest version of that GNU package, including the hash of its source tarball, and its canonical synopsis and description. -Additional information such as the package's dependencies and its +Additional information such as the package dependencies and its license needs to be figured out manually. For example, the following command returns a package definition for @@ -4329,19 +4367,19 @@ Specific command-line options are: @table @code @item --key-download=@var{policy} As for @code{guix refresh}, specify the policy to handle missing OpenPGP -keys when verifying the package's signature. @xref{Invoking guix +keys when verifying the package signature. @xref{Invoking guix refresh, @code{--key-download}}. @end table @item pypi @cindex pypi -Import meta-data from the @uref{https://pypi.python.org/, Python Package +Import metadata from the @uref{https://pypi.python.org/, Python Package Index}@footnote{This functionality requires Guile-JSON to be installed. @xref{Requirements}.}. Information is taken from the JSON-formatted description available at @code{pypi.python.org} and usually includes all the relevant information, including package dependencies. -The command below imports meta-data for the @code{itsdangerous} Python +The command below imports metadata for the @code{itsdangerous} Python package: @example @@ -4350,18 +4388,18 @@ guix import pypi itsdangerous @item gem @cindex gem -Import meta-data from @uref{https://rubygems.org/, +Import metadata from @uref{https://rubygems.org/, RubyGems}@footnote{This functionality requires Guile-JSON to be installed. @xref{Requirements}.}. Information is taken from the JSON-formatted description available at @code{rubygems.org} and includes most relevant information, including runtime dependencies. There are -some caveats, however. The meta-data doesn't distinguish between +some caveats, however. The metadata doesn't distinguish between synopses and descriptions, so the same string is used for both fields. Additionally, the details of non-Ruby dependencies required to build native extensions is unavailable and left as an exercise to the packager. -The command below imports meta-data for the @code{rails} Ruby package: +The command below imports metadata for the @code{rails} Ruby package: @example guix import gem rails @@ -4369,15 +4407,17 @@ guix import gem rails @item cpan @cindex CPAN -Import meta-data from @uref{https://www.metacpan.org/, MetaCPAN}. -Information is taken from the JSON-formatted meta-data provided through +Import metadata from @uref{https://www.metacpan.org/, MetaCPAN}@footnote{This +functionality requires Guile-JSON to be installed. +@xref{Requirements}.}. +Information is taken from the JSON-formatted metadata provided through @uref{https://api.metacpan.org/, MetaCPAN's API} and includes most relevant information, such as module dependencies. License information should be checked closely. If Perl is available in the store, then the @code{corelist} utility will be used to filter core modules out of the list of dependencies. -The command command below imports meta-data for the @code{Acme::Boolean} +The command command below imports metadata for the @code{Acme::Boolean} Perl module: @example @@ -4387,28 +4427,28 @@ guix import cpan Acme::Boolean @item cran @cindex CRAN @cindex Bioconductor -Import meta-data from @uref{http://cran.r-project.org/, CRAN}, the +Import metadata from @uref{http://cran.r-project.org/, CRAN}, the central repository for the @uref{http://r-project.org, GNU@tie{}R statistical and graphical environment}. -Information is extracted from the package's @code{DESCRIPTION} file. +Information is extracted from the @code{DESCRIPTION} file of the package. -The command command below imports meta-data for the @code{Cairo} +The command command below imports metadata for the @code{Cairo} R package: @example guix import cran Cairo @end example -When @code{--archive=bioconductor} is added, meta-data is imported from +When @code{--archive=bioconductor} is added, metadata is imported from @uref{http://www.bioconductor.org/, Bioconductor}, a repository of R packages for for the analysis and comprehension of high-throughput genomic data in bioinformatics. -Information is extracted from a package's @code{DESCRIPTION} file +Information is extracted from the @code{DESCRIPTION} file of a package published on the web interface of the Bioconductor SVN repository. -The command command below imports meta-data for the @code{GenomicRanges} +The command below imports metadata for the @code{GenomicRanges} R package: @example @@ -4416,7 +4456,7 @@ guix import cran --archive=bioconductor GenomicRanges @end example @item nix -Import meta-data from a local copy of the source of the +Import metadata from a local copy of the source of the @uref{http://nixos.org/nixpkgs/, Nixpkgs distribution}@footnote{This relies on the @command{nix-instantiate} command of @uref{http://nixos.org/nix/, Nix}.}. Package definitions in Nixpkgs are @@ -4447,7 +4487,7 @@ guix import nix ~/path/to/nixpkgs libreoffice @item hackage @cindex hackage -Import meta-data from Haskell community's central package archive +Import metadata from the Haskell community's central package archive @uref{https://hackage.haskell.org/, Hackage}. Information is taken from Cabal files and includes all the relevant information, including package dependencies. @@ -4457,10 +4497,10 @@ Specific command-line options are: @table @code @item --stdin @itemx -s -Read a Cabal file from the standard input. +Read a Cabal file from standard input. @item --no-test-dependencies @itemx -t -Do not include dependencies required by the test suites only. +Do not include dependencies required only by the test suites. @item --cabal-environment=@var{alist} @itemx -e @var{alist} @var{alist} is a Scheme alist defining the environment in which the @@ -4470,10 +4510,10 @@ The value associated with a flag has to be either the symbol @code{true} or @code{false}. The value associated with other keys has to conform to the Cabal file format definition. The default value associated with the keys @code{os}, @code{arch} and @code{impl} is -@samp{linux}, @samp{x86_64} and @samp{ghc} respectively. +@samp{linux}, @samp{x86_64} and @samp{ghc}, respectively. @end table -The command below imports meta-data for the latest version of the +The command below imports metadata for the latest version of the @code{HTTP} Haskell package without including test dependencies and specifying the value of the flag @samp{network-uri} as @code{false}: @@ -4490,7 +4530,7 @@ guix import hackage mtl-2.1.3.1 @item elpa @cindex elpa -Import meta-data from an Emacs Lisp Package Archive (ELPA) package +Import metadata from an Emacs Lisp Package Archive (ELPA) package repository (@pxref{Packages,,, emacs, The GNU Emacs Manual}). Specific command-line options are: @@ -4535,8 +4575,8 @@ gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18. gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0 @end example -It does so by browsing each package's FTP directory and determining the -highest version number of the source tarballs therein. The command +It does so by browsing the FTP directory of each package and determining +the highest version number of the source tarballs therein. The command knows how to update specific types of packages: GNU packages, ELPA packages, etc.---see the documentation for @option{--type} below. The are many packages, though, for which it lacks a method to determine @@ -4544,14 +4584,14 @@ whether a new upstream release is available. However, the mechanism is extensible, so feel free to get in touch with us to add a new method! When passed @code{--update}, it modifies distribution source files to -update the version numbers and source tarball hashes of those packages' +update the version numbers and source tarball hashes of those package recipes (@pxref{Defining Packages}). This is achieved by downloading each package's latest source tarball and its associated OpenPGP signature, authenticating the downloaded tarball against its signature using @command{gpg}, and finally computing its hash. When the public key used to sign the tarball is missing from the user's keyring, an attempt is made to automatically retrieve it from a public key server; -when it's successful, the key is added to the user's keyring; otherwise, +when this is successful, the key is added to the user's keyring; otherwise, @command{guix refresh} reports an error. The following options are supported: @@ -4609,6 +4649,8 @@ list of updaters). Currently, @var{updater} may be one of: the updater for GNU packages; @item gnome the updater for GNOME packages; +@item xorg +the updater for X.org packages; @item elpa the updater for @uref{http://elpa.gnu.org/, ELPA} packages; @item cran @@ -4617,10 +4659,14 @@ the updater for @uref{http://cran.r-project.org/, CRAN} packages; the updater for @uref{http://www.bioconductor.org/, Bioconductor} R packages; @item pypi the updater for @uref{https://pypi.python.org, PyPI} packages. +@item gem +the updater for @uref{https://rubygems.org, RubyGems} packages. +@item github +the updater for @uref{https://github.com, GitHub} packages. @end table -For instance, the following commands only checks for updates of Emacs -packages hosted at @code{elpa.gnu.org} and updates of CRAN packages: +For instance, the following command only checks for updates of Emacs +packages hosted at @code{elpa.gnu.org} and for updates of CRAN packages: @example $ guix refresh --type=elpa,cran @@ -4703,11 +4749,23 @@ Use @var{host} as the OpenPGP key server when importing a public key. @end table +The @code{github} updater uses the +@uref{https://developer.github.com/v3/, GitHub API} to query for new +releases. When used repeatedly e.g. when refreshing all packages, +GitHub will eventually refuse to answer any further API requests. By +default 60 API requests per hour are allowed, and a full refresh on all +GitHub packages in Guix requires more than this. Authentication with +GitHub through the use of an API token alleviates these limits. To use +an API token, set the environment variable @code{GUIX_GITHUB_TOKEN} to a +token procured from @uref{https://github.com/settings/tokens} or +otherwise. + + @node Invoking guix lint @section Invoking @command{guix lint} -The @command{guix lint} is meant to help package developers avoid common -errors and use a consistent style. It runs a number of checks on a -given set of packages in order to find common mistakes in their +The @command{guix lint} command is meant to help package developers avoid +common errors and use a consistent style. It runs a number of checks on +a given set of packages in order to find common mistakes in their definitions. Available @dfn{checkers} include (see @code{--list-checkers} for a complete list): @@ -4725,8 +4783,8 @@ Identify inputs that should most likely be native inputs. @itemx source-file-name Probe @code{home-page} and @code{source} URLs and report those that are invalid. Check that the source file name is meaningful, e.g. is not -just a version number or ``git-checkout'', and should not have a -@code{file-name} declared (@pxref{origin Reference}). +just a version number or ``git-checkout'', without a declared +@code{file-name} (@pxref{origin Reference}). @item cve Report known vulnerabilities found in the Common Vulnerabilities and @@ -4749,17 +4807,16 @@ If no package is given on the command line, then all packages are checked. The @var{options} may be zero or more of the following: @table @code +@item --list-checkers +@itemx -l +List and describe all the available checkers that will be run on packages +and exit. @item --checkers @itemx -c Only enable the checkers specified in a comma-separated list using the names returned by @code{--list-checkers}. -@item --list-checkers -@itemx -l -List and describe all the available checkers that will be run on packages -and exit. - @end table @node Invoking guix size @@ -4769,7 +4826,7 @@ The @command{guix size} command helps package developers profile the disk usage of packages. It is easy to overlook the impact of an additional dependency added to a package, or the impact of using a single output for a package that could easily be split (@pxref{Packages -with Multiple Outputs}). These are the typical issues that +with Multiple Outputs}). Such are the typical issues that @command{guix size} can highlight. The command can be passed a package specification such as @code{gcc-4.8} @@ -4796,12 +4853,12 @@ would be returned by: $ guix gc -R /gnu/store/@dots{}-coreutils-8.23 @end example -Here the output shows 3 columns next to store items. The first column, +Here the output shows three columns next to store items. The first column, labeled ``total'', shows the size in mebibytes (MiB) of the closure of the store item---that is, its own size plus the size of all its dependencies. The next column, labeled ``self'', shows the size of the -item itself. The last column shows the ratio of the item's size to the -space occupied by all the items listed here. +item itself. The last column shows the ratio of the size of the item +itself to the space occupied by all the items listed here. In this example, we see that the closure of Coreutils weighs in at 70@tie{}MiB, half of which is taken by libc. (That libc represents a @@ -4815,9 +4872,9 @@ dependencies, and measures its size in the store, similar to @command{du Coreutils}). When the given package is @emph{not} in the store, @command{guix size} -reports information based on information about the available substitutes -(@pxref{Substitutes}). This allows it to profile disk usage of store -items that are not even on disk, only available remotely. +reports information based on the available substitutes +(@pxref{Substitutes}). This makes it possible it to profile disk usage of +store items that are not even on disk, only available remotely. The available options are: @@ -4828,7 +4885,7 @@ Use substitute information from @var{urls}. @xref{client-substitute-urls, the same option for @code{guix build}}. @item --map-file=@var{file} -Write to @var{file} a graphical map of disk usage as a PNG file. +Write a graphical map of disk usage in PNG format to @var{file}. For the example above, the map looks like this: @@ -4852,11 +4909,11 @@ Consider packages for @var{system}---e.g., @code{x86_64-linux}. @cindex DAG Packages and their dependencies form a @dfn{graph}, specifically a directed acyclic graph (DAG). It can quickly become difficult to have a -mental model of the package DAG, so the @command{guix graph} command is -here to provide a visual representation of the DAG. @command{guix -graph} emits a DAG representation in the input format of +mental model of the package DAG, so the @command{guix graph} command +provides a visual representation of the DAG. @command{guix graph} +emits a DAG representation in the input format of @uref{http://www.graphviz.org/, Graphviz}, so its output can be passed -directly to Graphviz's @command{dot} command, for instance. The general +directly to the @command{dot} command of Graphviz. The general syntax is: @example @@ -4877,15 +4934,15 @@ The output looks like this: Nice little graph, no? -But there's more than one graph! The one above is concise: it's the +But there is more than one graph! The one above is concise: it is the graph of package objects, omitting implicit inputs such as GCC, libc, -grep, etc. It's often useful to have such a concise graph, but -sometimes you want to see more details. @command{guix graph} supports -several types of graphs, allowing you to choose the level of details: +grep, etc. It is often useful to have such a concise graph, but +sometimes one may want to see more details. @command{guix graph} supports +several types of graphs, allowing you to choose the level of detail: @table @code @item package -This is the default type, the one we used above. It shows the DAG of +This is the default type used in the example above. It shows the DAG of package objects, excluding implicit dependencies. It is concise, but filters out many details. @@ -4905,7 +4962,7 @@ guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf At the bottom of the graph, we see all the implicit inputs of @var{gnu-build-system} (@pxref{Build Systems, @code{gnu-build-system}}). -Now, note that the dependencies of those implicit inputs---that is, the +Now, note that the dependencies of these implicit inputs---that is, the @dfn{bootstrap dependencies} (@pxref{Bootstrapping})---are not shown here, for conciseness. @@ -4920,11 +4977,11 @@ Similar to @code{bag}, but also showing origins and their dependencies. This is the most detailed representation: It shows the DAG of derivations (@pxref{Derivations}) and plain store items. Compared to the above representation, many additional nodes are visible, including -builds scripts, patches, Guile modules, etc. +build scripts, patches, Guile modules, etc. @end table -All the above types correspond to @emph{build-time dependencies}. The +All the types above correspond to @emph{build-time dependencies}. The following graph type represents the @emph{run-time dependencies}: @table @code @@ -4967,7 +5024,7 @@ guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)' The purpose of @command{guix environment} is to assist hackers in creating reproducible development environments without polluting their package profile. The @command{guix environment} tool takes one or more -packages, builds all of the necessary inputs, and creates a shell +packages, builds all of their inputs, and creates a shell environment to use them. The general syntax is: @@ -4983,12 +5040,12 @@ GNU@tie{}Guile: guix environment guile @end example -If the specified packages are not built yet, @command{guix environment} -automatically builds them. The new shell's environment is an augmented +If the needed dependencies are not built yet, @command{guix environment} +automatically builds them. The environment of the new shell is an augmented version of the environment that @command{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, +environment, in which the original environment variables have been unset, use the @code{--pure} option@footnote{Users sometimes wrongfully augment environment variables such as @code{PATH} in their @file{~/.bashrc} file. As a consequence, when @code{guix environment} launches it, Bash @@ -5001,7 +5058,7 @@ details on Bash start-up files.}. @vindex GUIX_ENVIRONMENT @command{guix environment} defines the @code{GUIX_ENVIRONMENT} -variable in the shell it spaws. This allows users to, say, define a +variable in the shell it spawns. This allows users to, say, define a specific prompt for development environments in their @file{.bashrc} (@pxref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}): @@ -5093,6 +5150,13 @@ guix environment --ad-hoc -e '(@@ (gnu) %base-packages)' starts a shell with all the GuixSD base packages available. +The above commands only the use default output of the given packages. +To select other outputs, two element tuples can be specified: + +@example +guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")' +@end example + @item --load=@var{file} @itemx -l @var{file} Create an environment for the package or list of packages that the code @@ -5121,7 +5185,7 @@ runs @command{guile} in an environment where Guile and Guile-SDL are available. Note that this example implicitly asks for the default output of -@code{guile} and @code{guile-sdl} but it is possible to ask for a +@code{guile} and @code{guile-sdl}, but it is possible to ask for a specific output---e.g., @code{glib:bin} asks for the @code{bin} output of @code{glib} (@pxref{Packages with Multiple Outputs}). @@ -5195,7 +5259,7 @@ build} supports (@pxref{Common Build Options}). @section Invoking @command{guix publish} The purpose of @command{guix publish} is to enable users to easily share -their store with others, which can then use it as a substitute server +their store with others, who can then use it as a substitute server (@pxref{Substitutes}). When @command{guix publish} runs, it spawns an HTTP server which allows @@ -5206,7 +5270,7 @@ the @code{hydra.gnu.org} build farm. For security, each substitute is signed, allowing recipients to check their authenticity and integrity (@pxref{Substitutes}). Because -@command{guix publish} uses the system's signing key, which is only +@command{guix publish} uses the signing key of the system, which is only readable by the system administrator, it must be started as root; the @code{--user} option makes it drop root privileges early on. @@ -5270,12 +5334,12 @@ of the @code{operating-system} declaration (@pxref{guix-publish-service, @cindex verifiable builds Do the binaries provided by this server really correspond to the source -code it claims to build? Is this package's build process deterministic? +code it claims to build? Is a package build process deterministic? These are the questions the @command{guix challenge} command attempts to answer. The former is obviously an important question: Before using a substitute -server (@pxref{Substitutes}), you'd rather @emph{verify} that it +server (@pxref{Substitutes}), one had better @emph{verify} that it provides the right binaries, and thus @emph{challenge} it. The latter is what enables the former: If package builds are deterministic, then independent builds of the package should yield the exact same result, @@ -5291,7 +5355,7 @@ one store file name should map to exactly one build output. mapping by comparing the build outputs of several independent builds of any given store item. -The command's output looks like this: +The command output looks like this: @smallexample $ guix challenge --substitute-urls="http://hydra.gnu.org http://guix.example.org" @@ -5330,7 +5394,7 @@ results, the inclusion of random numbers, and directory listings sorted by inode number. See @uref{http://reproducible.debian.net/howto/}, for more information. -To find out what's wrong with this Git binary, we can do something along +To find out what is wrong with this Git binary, we can do something along these lines (@pxref{Invoking guix archive}): @example @@ -5347,11 +5411,11 @@ works great for text files. When binary files differ, a better option is @uref{http://diffoscope.org/, Diffoscope}, a tool that helps visualize differences for all kinds of files. -Once you've done that work, you can tell whether the differences are due +Once you have done that work, you can tell whether the differences are due to a non-deterministic build process or to a malicious server. We try hard to remove sources of non-determinism in packages to make it easier -to verify substitutes, but of course, this is a process, one that -involves not just Guix but a large part of the free software community. +to verify substitutes, but of course, this is a process that +involves not just Guix, but a large part of the free software community. In the meantime, @command{guix challenge} is one tool to help address the problem. @@ -5364,7 +5428,7 @@ $ guix challenge @var{package} @end example @noindent -... where @var{package} is a package specification such as +where @var{package} is a package specification such as @code{guile-2.0} or @code{glibc:debug}. The general syntax is: @@ -5421,9 +5485,9 @@ guix container exec @var{pid} @var{program} @var{arguments}@dots{} @end example @var{pid} specifies the process ID of the running container. -@var{program} specifies an executable file name within the container's -root file system. @var{arguments} are the additional options that will -be passed to @var{program}. +@var{program} specifies an executable file name within the root file +system of the container. @var{arguments} are the additional options that +will be passed to @var{program}. The following command launches an interactive login shell inside a GuixSD container, started by @command{guix system container}, and whose @@ -5434,7 +5498,7 @@ guix container exec 9001 /run/current-system/profile/bin/bash --login @end example Note that the @var{pid} cannot be the parent process of a container. It -must be the container's PID 1 or one of its child processes. +must be PID 1 of the container or one of its child processes. @end table @@ -5464,7 +5528,7 @@ running @command{guix package} (@pxref{Invoking guix package}): guix package --list-available @end example -Our goal has been to provide a practical 100% free software distribution of +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. @@ -5481,11 +5545,12 @@ Intel 32-bit architecture (IA32), Linux-Libre kernel; @item armhf-linux ARMv7-A architecture with hard float, Thumb-2 and NEON, -using the EABI hard-float ABI, and Linux-Libre kernel. +using the EABI hard-float application binary interface (ABI), +and Linux-Libre kernel. @item mips64el-linux little-endian 64-bit MIPS processors, specifically the Loongson series, -n32 application binary interface (ABI), and Linux-Libre kernel. +n32 ABI, and Linux-Libre kernel. @end table @@ -5493,7 +5558,7 @@ GuixSD itself is currently only available on @code{i686} and @code{x86_64}. @noindent For information on porting to other architectures or kernels, -@xref{Porting}. +@pxref{Porting}. @menu * System Installation:: Installing the whole operating system. @@ -5527,6 +5592,15 @@ link that follows: @pxref{Help,,, info, Info: An Introduction}. Hit @kbd{l} afterwards to come back here. @end ifinfo +@menu +* Limitations:: What you can expect. +* USB Stick Installation:: Preparing the installation medium. +* Preparing for Installation:: Networking, partitioning, etc. +* Proceeding with the Installation:: The real thing. +* Building the Installation Image:: How this comes to be. +@end menu + +@node Limitations @subsection Limitations As of version @value{VERSION}, the Guix System Distribution (GuixSD) is @@ -5534,7 +5608,7 @@ not production-ready. It may contain bugs and lack important features. Thus, if you are looking for a stable production system that respects your freedom as a computer user, a good solution at this point is to consider @url{http://www.gnu.org/distros/free-distros.html, one of -more established GNU/Linux distributions}. We hope you can soon switch +the more established GNU/Linux distributions}. We hope you can soon switch to the GuixSD without fear, of course. In the meantime, you can also keep using your distribution and try out the package manager on top of it (@pxref{Installation}). @@ -5550,7 +5624,7 @@ get a feel of what that means.) @item The system does not yet provide full GNOME and KDE desktops. Xfce and -Enlightenment are available though, if graphical desktop environments +Enlightenment are available, though, if graphical desktop environments are your thing, as well as a number of X11 window managers. @item @@ -5561,14 +5635,15 @@ Few system services are currently supported out-of-the-box (@pxref{Services}). @item -More than 2,000 packages are available, but you may +More than 3,000 packages are available, but you may occasionally find that a useful package is missing. @end itemize -You've been warned. But more than a disclaimer, this is an invitation -to report issues (and success stories!), and join us in improving it. +You have been warned! But more than a disclaimer, this is an invitation +to report issues (and success stories!), and to join us in improving it. @xref{Contributing}, for more info. +@node USB Stick Installation @subsection USB Stick Installation An installation image for USB sticks can be downloaded from @@ -5598,8 +5673,8 @@ xz -d guixsd-usb-install-@value{VERSION}.@var{system}.xz @end example @item -Insert a USB stick of 1@tie{}GiB or more in your machine, and determine -its device name. Assuming that USB stick is known as @file{/dev/sdX}, +Insert a USB stick of 1@tie{}GiB or more into your machine, and determine +its device name. Assuming that the USB stick is known as @file{/dev/sdX}, copy the image with: @example @@ -5613,6 +5688,7 @@ Once this is done, you should be able to reboot the system and boot from the USB stick. The latter usually requires you to get in the BIOS' boot menu, where you can choose to boot from the USB stick. +@node Preparing for Installation @subsection Preparing for Installation Once you have successfully booted the image on the USB stick, you should @@ -5623,47 +5699,123 @@ Introduction}). 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. -To install the system, you would: +@subsubsection Keyboard Layout -@enumerate +@cindex keyboard layout +The installation image uses the US qwerty keyboard layout. If you want +to change it, you can use the @command{loadkeys} command. For example, +the following command selects the Dvorak keyboard layout: -@item -Configure the network, by running: +@example +loadkeys dvorak +@end example + +See the files under @file{/run/current-system/profile/share/keymaps} for +a list of available keyboard layouts. Run @command{man loadkeys} for +more information. + +@subsubsection Networking + +Run the following command see what your network interfaces are called: @example -ifconfig eno1 up && dhclient eno1 +ifconfig -a @end example -to get an automatically assigned IP address from the wired -network interface controller@footnote{ @c http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 -The name @code{eno1} is for the first on-board Ethernet controller. The -interface name for an Ethernet controller that is in the first slot of -the first PCI bus, for instance, would be @code{enp1s0}. Use -@command{ifconfig -a} to list all the available network interfaces.}, -or using the @command{ifconfig} command. +Wired interfaces have a name starting with @samp{e}; for example, the +interface corresponding to the first on-board Ethernet controller is +called @samp{eno1}. Wireless interfaces have a name starting with +@samp{w}, like @samp{w1p2s0}. -The system automatically loads drivers for your network interface -controllers. +@table @asis +@item Wired connection +To configure a wired network run the following command, substituting +@var{interface} with the name of the wired interface you want to use. + +@example +ifconfig @var{interface} up +@end example + +@item Wireless connection +To configure wireless networking, you can create a configuration file +for the @command{wpa_supplicant} configuration tool (its location is not +important) using one of the available text editors such as +@command{zile}: + +@example +zile wpa_supplicant.conf +@end example + +As an example, the following stanza can go to this file and will work +for many wireless networks, provided you give the actual SSID and +passphrase for the network you are connecting to: + +@example +network=@{ + ssid=@var{my-ssid} + key_mgmt=WPA-PSK + psk="the network's secret passphrase" +@} +@end example + +Start the wireless service and run it in the background with the +following command (substitute @var{interface} with the name of the +network interface you want to use): + +@example +wpa_supplicant -c wpa_supplicant.conf -i @var{interface} -B +@end example + +Run @command{man wpa_supplication} for more information. +@end table + +At this point, you need to acquire an IP address. On a network where IP +addresses are automatically assigned @i{via} DHCP, you can run: + +@example +dhclient @var{interface} +@end example + +Try to ping a server to see if networking is up and running: + +@example +ping -c 3 gnu.org +@end example Setting up network access is almost always a requirement because the image does not contain all the software and tools that may be needed. -@item -Unless this has already been done, you must partition, and then format -the target partition. +@subsubsection Disk Partitioning + +Unless this has already been done, the next step is to partition, and +then format the target partition(s). + +The installation image includes several partitioning tools, including +Parted (@pxref{Overview,,, parted, GNU Parted User Manual}), +@command{fdisk}, and @command{cfdisk}. Run it and set up your disk with +the partition layout you want: + +@example +cfdisk +@end example + +Once you are done partitioning the target hard disk drive, you have to +create a file system on the relevant partition(s)@footnote{Currently +GuixSD pretty much assumes an ext4 file system. In particular, code +that reads partition UUIDs and labels only works with ext4. This will +be fixed in the future.}. Preferably, assign partitions a label so that you can easily and reliably refer to them in @code{file-system} declarations (@pxref{File Systems}). This is typically done using the @code{-L} option of -@command{mkfs.ext4} and related commands. +@command{mkfs.ext4} and related commands. So, assuming the target root +partition lives at @file{/dev/sda1}, a file system with the label +@code{my-root} can be created with: -Be sure that your partition labels match the value of their respective -@code{device} fields in your @code{file-system} configuration, if your -@code{file-system} configuration sets the value of @code{title} to -@code{'label}, as do the example configurations found on the USB -installation image under @file{/etc/configuration} (@pxref{Using the -Configuration System}). +@example +mkfs.ext4 -L my-root /dev/sda1 +@end example @c FIXME: Uncomment this once GRUB fully supports encrypted roots. @c A typical command sequence may be: @@ -5676,37 +5828,66 @@ Configuration System}). @c # mkfs.ext4 -L my-root /dev/mapper/my-partition @c @end example -The installation image includes Parted (@pxref{Overview,,, parted, GNU -Parted User Manual}), @command{fdisk}, Cryptsetup/LUKS for disk -encryption, and e2fsprogs, the suite of tools to manipulate -ext2/ext3/ext4 file systems. +In addition to e2fsprogs, the suite of tools to manipulate +ext2/ext3/ext4 file systems, the installation image includes +Cryptsetup/LUKS for disk encryption. -@item -Once that is done, mount the target root partition under @file{/mnt}. +Once that is done, mount the target root partition under @file{/mnt} +with a command like (again, assuming @file{/dev/sda1} is the root +partition): -@item -Lastly, run @code{herd start cow-store /mnt}. +@example +mount /dev/sda1 /mnt +@end example -This will make @file{/gnu/store} copy-on-write, such that packages added -to it during the installation phase will be written to the target disk -rather than kept in memory. +@node Proceeding with the Installation +@subsection Proceeding with the Installation -@end enumerate +With the target partitions ready and the target root mounted on +@file{/mnt}, we're ready to go. First, run: +@example +herd start cow-store /mnt +@end example -@subsection Proceeding with the Installation +This makes @file{/gnu/store} copy-on-write, such that packages added to +it during the installation phase are written to the target disk rather +than kept in memory. -With the target partitions ready, you now have to edit a file and +Next, you have to edit a file and provide the declaration of the operating system to be installed. To that end, the installation system comes with two text editors: GNU nano (@pxref{Top,,, nano, GNU nano Manual}), and GNU Zile, an Emacs clone. It is better to store that file on the target root file system, say, as @file{/mnt/etc/config.scm}. -@xref{Using the Configuration System}, for examples of operating system -configurations. These examples are available under -@file{/etc/configuration} in the installation image, so you can copy -them and use them as a starting point for your own configuration. +@xref{Using the Configuration System}, for an overview of the +configuration file. The example configurations discussed in that +section are available under @file{/etc/configuration} in the +installation image. Thus, to get started with a system configuration +providing a graphical display server (a ``desktop'' system), you can run +something along these lines: + +@example +# mkdir /mnt/etc +# cp /etc/configuration/desktop.scm /mnt/etc/config.scm +# zile /mnt/etc/config.scm +@end example + +You should pay attention to what your configuration file contains, and +in particular: + +@itemize +@item +Make sure the @code{grub-configuration} form refers to the device you +want to install GRUB on. + +@item +Be sure that your partition labels match the value of their respective +@code{device} fields in your @code{file-system} configuration, assuming +your @code{file-system} configuration sets the value of @code{title} to +@code{'label}. +@end itemize Once you are done preparing the configuration file, the new system must be initialized (remember that the target root file system is mounted @@ -5717,7 +5898,7 @@ guix system init /mnt/etc/config.scm /mnt @end example @noindent -This will copy all the necessary files, and install GRUB on +This copies all the necessary files and installs GRUB on @file{/dev/sdX}, unless you pass the @option{--no-grub} option. For more information, @pxref{Invoking guix system}. This command may trigger downloads or builds of missing packages, which can take some time. @@ -5733,6 +5914,7 @@ Join us on @code{#guix} on the Freenode IRC network or on @file{guix-devel@@gnu.org} to share your experience---good or not so good. +@node Building the Installation Image @subsection Building the Installation Image The installation image described above was built using the @command{guix @@ -6137,7 +6319,12 @@ is interpreted as a partition label name; when it is @code{uuid}, @code{device} is interpreted as a partition unique identifier (UUID). UUIDs may be converted from their string representation (as shown by the -@command{tune2fs -l} command) using the @code{uuid} form, like this: +@command{tune2fs -l} command) using the @code{uuid} form@footnote{The +@code{uuid} form expects 16-byte UUIDs as defined in +@uref{https://tools.ietf.org/html/rfc4122, RFC@tie{}4122}. This is the +form of UUID used by the ext2 family of file systems and others, but it +is different from ``UUIDs'' found in FAT file systems, for instance.}, +like this: @example (file-system @@ -6452,17 +6639,17 @@ Usually, you will want to specify the default locale for the machine using the @code{locale} field of the @code{operating-system} declaration (@pxref{operating-system Reference, @code{locale}}). -That locale must be among the @dfn{locale definitions} that are known to -the system---and these are specified in the @code{locale-definitions} -slot of @code{operating-system}. The default value includes locale -definitions for some widely used locales, but not for all the available -locales, in order to save space. +The selected locale is automatically added to the @dfn{locale +definitions} known to the system if needed, with its codeset inferred +from its name---e.g., @code{bo_CN.utf8} will be assumed to use the +@code{UTF-8} codeset. Additional locale definitions can be specified in +the @code{locale-definitions} slot of @code{operating-system}---this is +useful, for instance, if the codeset could not be inferred from the +locale name. The default set of locale definitions includes some widely +used locales, but not all the available locales, in order to save space. -If the locale specified in the @code{locale} field is not among the -definitions listed in @code{locale-definitions}, @command{guix system} -raises an error. In that case, you should add the locale definition to -the @code{locale-definitions} field. For instance, to add the North -Frisian locale for Germany, the value of that field may be: +For instance, to add the North Frisian locale for Germany, the value of +that field may be: @example (cons (locale-definition @@ -6844,6 +7031,7 @@ Run @var{udev}, which populates the @file{/dev} directory dynamically. @end deffn @deffn {Scheme Procedure} console-keymap-service @var{file} +@cindex keyboard layout Return a service to load console keymap from @var{file} using @command{loadkeys} command. @end deffn @@ -9204,7 +9392,7 @@ guix system @var{options}@dots{} @var{action} @var{file} @var{file} must be the name of a file containing an @code{operating-system} declaration. @var{action} specifies how the -operating system is instantiate. Currently the following values are +operating system is instantiated. Currently the following values are supported: @table @code @@ -9439,7 +9627,7 @@ example graph. @end table @node Running GuixSD in a VM -@subsection Running GuixSD in a virtual machine +@subsection Running GuixSD in a Virtual Machine One way to run GuixSD in a virtual machine (VM) is to build a GuixSD virtual machine image using @command{guix system vm-image} @@ -9670,7 +9858,7 @@ the composition of the extensions. Udev extensions are composed into a list of rules, but the udev service value is itself a @code{<udev-configuration>} record. So here, we -extend that record by appending the list of rules is contains to the +extend that record by appending the list of rules it contains to the list of contributed rules. @end table @@ -9864,11 +10052,11 @@ extend it by passing it lists of packages to add to the system profile. @cindex PID 1 @cindex init system -The @code{(gnu services shepherd)} provides a way to define services -managed by the GNU@tie{}Shepherd, which is GuixSD initialization -system---the first process that is started when the system boots, -aka. PID@tie{}1 (@pxref{Introduction,,, shepherd, The GNU Shepherd -Manual}). +The @code{(gnu services shepherd)} module provides a way to define +services managed by the GNU@tie{}Shepherd, which is the GuixSD +initialization system---the first process that is started when the +system boots, aka. PID@tie{}1 (@pxref{Introduction,,, shepherd, The GNU +Shepherd Manual}). Services in the Shepherd can depend on each other. For instance, the SSH daemon may need to be started after the syslog daemon has been @@ -10138,7 +10326,7 @@ Free software packages are usually distributed in the form of all the source files. Adding a package to the distribution means essentially two things: adding a @dfn{recipe} that describes how to build the package, including a list of other packages required to build -it, and adding @dfn{package meta-data} along with that recipe, such as a +it, and adding @dfn{package metadata} along with that recipe, such as a description and licensing information. In Guix all this information is embodied in @dfn{package definitions}. @@ -10322,7 +10510,26 @@ field to, say, 7 digits. It avoids an aesthetic annoyance (assuming aesthetics have a role to play here) as well as problems related to OS limits such as the maximum shebang length (127 bytes for the Linux kernel.) It is best to use the full commit identifiers in -@code{origin}s, though, to avoid ambiguities. +@code{origin}s, though, to avoid ambiguities. A typical package +definition may look like this: + +@example +(define my-package + (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")) + (package + (version (string-append "0.9-1." + (string-take commit 7))) + (source (origin + (method git-fetch) + (uri (git-reference + (url "git://example.org/my-package.git") + (commit commit))) + (sha256 (base32 "1mbikn@dots{}")) + (file-name (string-append "my-package-" version + "-checkout")))) + ;; @dots{} + ))) +@end example @node Synopses and Descriptions @subsection Synopses and Descriptions |