gnu: ghostscript: Build and install shared library and header files.
[jackhill/guix/guix.git] / doc / guix.texi
index 29e1245..8b49630 100644 (file)
@@ -80,6 +80,7 @@ Documentation License.''
 * Package Management::          Package installation, upgrade, etc.
 * Programming Interface::       Using Guix in Scheme.
 * Utilities::                   Package management commands.
+* GNU Distribution::            Software for your friendly GNU system.
 
 * Acknowledgments::             Thanks!
 * GNU Free Documentation License::  The license of this manual.
@@ -131,6 +132,10 @@ Guix has a command-line interface allowing users to build, install,
 upgrade, and remove packages, as well as a Scheme programming interface.
 The remainder of this manual describes them.
 
+Last but not least, Guix is used to build a distribution of the GNU
+system, with many GNU and non-GNU free software packages.  @xref{GNU
+Distribution}.
+
 @c *********************************************************************
 @node Installation
 @chapter Installation
@@ -216,11 +221,14 @@ regarded as pure functions (@pxref{Introduction}).
 On a GNU/Linux system, a build user pool may be created like this (using
 Bash syntax and the @code{shadow} commands):
 
+@c See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html
+@c for why `-G' is needed.
 @example
 # groupadd guix-builder
 # for i in `seq 1 10`;
   do
-    useradd -g guix-builder -d /var/empty -s `which nologin` \
+    useradd -g guix-builder -G guix-builder           \
+            -d /var/empty -s `which nologin`          \
             -c "Guix build user $i" guix-builder$i;
   done
 @end example
@@ -427,10 +435,13 @@ Each @file{/nix/store} package directory name contains a hash of all the
 inputs that were used to build that package---compiler, libraries, build
 scripts, etc.  This direct correspondence allows users to make sure a
 given package installation matches the current state of their
-distribution.
+distribution, and helps maximize @dfn{reproducibility}.
 
+@c FIXME: Remove footnote when it's implemented.
 This foundation allows Guix to support @dfn{transparent binary/source
-deployment}.  When a pre-built binary for a @file{/nix/store} path is
+deployment}@footnote{This feature is not implemented as of version
+@value{VERSION}.  Please contact @email{bug-guix@@gnu.org} for more
+details.}.  When a pre-built binary for a @file{/nix/store} path is
 available from an external source, Guix just downloads it; otherwise, it
 builds the package from source, locally.
 
@@ -490,6 +501,13 @@ Remove @var{package}.
 @itemx -u @var{regexp}
 Upgrade all the installed packages matching @var{regexp}.
 
+@item --roll-back
+Roll back to the previous @dfn{generation} of the profile---i.e., undo
+the last transaction.
+
+When combined with options such as @code{--install}, roll back occurs
+before any other actions.
+
 @item --profile=@var{profile}
 @itemx -p @var{profile}
 Use @var{profile} instead of the user's default profile.
@@ -528,9 +546,9 @@ the store.
 
 @item --list-available[=@var{regexp}]
 @itemx -A [@var{regexp}]
-List packages currently available in the software distribution.  When
-@var{regexp} is specified, list only installed packages whose name
-matches @var{regexp}.
+List packages currently available in the software distribution
+(@pxref{GNU Distribution}).  When @var{regexp} is specified, list only
+installed packages whose name matches @var{regexp}.
 
 For each package, print the following items separated by tabs: its name,
 its version string, the parts of the package (@code{out} for the main
@@ -730,7 +748,9 @@ These are keyword arguments (@pxref{Optional Arguments, keyword
 arguments in Guile,, guile, GNU Guile Reference Manual}).  They are
 passed to @var{gnu-build-system}, which interprets them as meaning ``do
 not run @code{make check}'', and ``run @file{configure} with the
-@code{--enable-silent-rules} flag''.
+@code{--enable-silent-rules} flag''.  The value of these keyword
+parameters is actually evaluated in the @dfn{build stratum}---i.e., by a
+Guile process launched by the daemon (@pxref{Derivations}).
 
 Once a package definition is in place@footnote{Simple package
 definitions like the one above may be automatically converted from the
@@ -745,9 +765,8 @@ The build actions it prescribes may then be realized by using the
 @code{build-derivations} procedure (@pxref{The Store}).
 
 @deffn {Scheme Procedure} package-derivation @var{store} @var{package} [@var{system}]
-Return the derivation of @var{package} for @var{system}.  The result is
-the file name of the derivation---i.e., a @code{.drv} file under
-@code{/nix/store}.
+Return the derivation path and corresponding @code{<derivation>} object
+of @var{package} for @var{system} (@pxref{Derivations}).
 
 @var{package} must be a valid @code{<package>} object, and @var{system}
 must be a string denoting the target system type---e.g.,
@@ -809,13 +828,146 @@ path.  @var{references} is the list of store paths referred to by the
 resulting store path.
 @end deffn
 
+@deffn {Scheme Procedure} build-derivations @var{server} @var{derivations}
+Build @var{derivations} (a list of derivation paths), and return when
+the worker is done building them.  Return @code{#t} on success.
+@end deffn
+
 @c FIXME
 @i{This section is currently incomplete.}
 
 @node Derivations
 @section Derivations
 
-@code{(guix derivations)}
+@cindex derivations
+Low-level build actions and the environment in which they are performed
+are represented by @dfn{derivations}.  A derivation contain the
+following pieces of information:
+
+@itemize
+@item
+The outputs of the derivation---derivations produce at least one file or
+directory in the store, but may produce more.
+
+@item
+The inputs of the derivations, which may be other derivations or plain
+files in the store (patches, build scripts, etc.)
+
+@item
+The system type targeted by the derivation---e.g., @code{x86_64-linux}.
+
+@item
+The file name of a build script in the store, along with the arguments
+to be passed.
+
+@item
+A list of environment variables to be defined.
+
+@end itemize
+
+@cindex derivation path
+Derivations allow clients of the daemon to communicate build actions to
+the store.  They exist in two forms: as an in-memory representation,
+both on the client- and daemon-side, and as files in the store whose
+name end in @code{.drv}---these files are referred to as @dfn{derivation
+paths}.  Derivations paths can be passed to the @code{build-derivations}
+procedure to perform the build actions they prescribe (@pxref{The
+Store}).
+
+The @code{(guix derivations)} module provides a representation of
+derivations as Scheme objects, along with procedures to create and
+otherwise manipulate derivations.  The lowest-level primitive to create
+a derivation is the @code{derivation} procedure:
+
+@deffn {Scheme Procedure} derivation @var{store} @var{name} @var{system} @var{builder} @var{args} @var{env-vars} @var{inputs} [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] [#:hash-mode #f]
+Build a derivation with the given arguments.  Return the resulting store
+path and @code{<derivation>} object.
+
+When @var{hash}, @var{hash-algo}, and @var{hash-mode} are given, a
+@dfn{fixed-output derivation} is created---i.e., one whose result is
+known in advance, such as a file download.
+@end deffn
+
+@noindent
+Here's an example with a shell script as its builder, assuming
+@var{store} is an open connection to the daemon, and @var{bash} points
+to a Bash executable in the store:
+
+@lisp
+(use-modules (guix utils)
+             (guix store)
+             (guix derivations))
+
+(call-with-values
+  (lambda ()
+    (let ((builder   ; add the Bash script to the store
+           (add-text-to-store store "my-builder.sh"
+                              "echo hello world > $out\n" '())))
+      (derivation store "foo" (%current-system)
+                  bash `("-e" ,builder)
+                  '(("HOME" . "/homeless")) '())))
+  list)
+@result{} ("/nix/store/@dots{}-foo.drv" #<<derivation> @dots{}>)
+@end lisp
+
+As can be guessed, this primitive is cumbersome to use directly.  An
+improved variant is @code{build-expression->derivation}, which allows
+the caller to directly pass a Guile expression as the build script:
+
+@deffn {Scheme Procedure} build-expression->derivation @var{store} @var{name} @var{system} @var{exp} @var{inputs} [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] [#:env-vars '()] [#:modules '()] [#:guile-for-build #f]
+Return a derivation that executes Scheme expression @var{exp} as a
+builder for derivation @var{name}.  @var{inputs} must be a list of
+@code{(name drv-path sub-drv)} tuples; when @var{sub-drv} is omitted,
+@code{"out"} is assumed.  @var{modules} is a list of names of Guile
+modules from the current search path to be copied in the store,
+compiled, and made available in the load path during the execution of
+@var{exp}---e.g., @code{((guix build utils) (guix build
+gnu-build-system))}.
+
+@var{exp} is evaluated in an environment where @code{%outputs} is bound
+to a list of output/path pairs, and where @code{%build-inputs} is bound
+to a list of string/output-path pairs made from @var{inputs}.
+Optionally, @var{env-vars} is a list of string pairs specifying the name
+and value of environment variables visible to the builder.  The builder
+terminates by passing the result of @var{exp} to @code{exit}; thus, when
+@var{exp} returns @code{#f}, the build is considered to have failed.
+
+@var{exp} is built using @var{guile-for-build} (a derivation).  When
+@var{guile-for-build} is omitted or is @code{#f}, the value of the
+@code{%guile-for-build} fluid is used instead.
+@end deffn
+
+@noindent
+Here's an example of a single-output derivation that creates a directory
+containing one file:
+
+@lisp
+(let ((builder '(let ((out (assoc-ref %outputs "out")))
+                  (mkdir out)    ; create /nix/store/@dots{}-goo
+                  (call-with-output-file (string-append out "/test")
+                    (lambda (p)
+                      (display '(hello guix) p))))))
+  (build-expression->derivation store "goo" (%current-system)
+                                builder '()))
+
+@result{} "/nix/store/@dots{}-goo.drv"
+@result{} #<<derivation> @dots{}>
+@end lisp
+
+@cindex strata of code
+Remember that the build expression passed to
+@code{build-expression->derivation} is run by a separate Guile process
+than the one that calls @code{build-expression->derivation}: it is run
+by a Guile process launched by the daemon, typically in a chroot.  So,
+while there is a single language for both the @dfn{host} and the build
+side, there are really two @dfn{strata} of code: the host-side, and the
+build-side code@footnote{The term @dfn{stratum} in this context was
+coined by Manuel Serrano et al. in the context of their work on Hop.}.
+This distinction is important to keep in mind, notably when using
+higher-level constructs such as @var{gnu-build-system} (@pxref{Defining
+Packages}).  For this reason, Guix modules that are meant to be used in
+the build stratum are kept in the @code{(guix build @dots{})} name
+space.
 
 @c *********************************************************************
 @node Utilities
@@ -837,8 +989,9 @@ guix-build @var{options} @var{package-or-derivation}@dots{}
 @end example
 
 @var{package-or-derivation} may be either the name of a package found in
-the software distribution such as @code{coreutils}, or a derivation such
-as @file{/nix/store/xxx-coreutils-8.19.drv}.  Alternatively, the
+the software distribution such as @code{coreutils} or
+@code{coreutils-8.20}, or a derivation such as
+@file{/nix/store/@dots{}-coreutils-8.19.drv}.  Alternatively, the
 @code{--expression} option may be used to specify a Scheme expression
 that evaluates to a package; this is useful when disambiguation among
 several same-named packages or package variants is needed.
@@ -851,7 +1004,7 @@ The @var{options} may be zero or more of the following:
 @itemx -e @var{expr}
 Build the package @var{expr} evaluates to.
 
-For example, @var{expr} may be @code{(@@ (distro packages guile)
+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.
 
@@ -913,6 +1066,48 @@ the @code{package-derivation} procedure of the @code{(guix packages)}
 module, and to the @code{build-derivations} procedure of the @code{(guix
 store)} module.
 
+@c *********************************************************************
+@node GNU Distribution
+@chapter GNU Distribution
+
+Guix comes with a distribution of free software@footnote{The term
+``free'' here refers to the
+@url{http://www.gnu.org/philosophy/free-sw.html,freedom provided to
+users of that software}.}  that form the basis of the GNU system.  This
+includes core GNU packages such as GNU libc, GCC, and Binutils, as well
+as many GNU and non-GNU applications.  The complete list of available
+packages can be seen by running @command{guix-package} (@pxref{Invoking
+guix-package}):
+
+@example
+guix-package --list-available
+@end example
+
+The package definitions of the distribution may are provided by Guile
+modules in the @code{(gnu packages ...)} name space---for instance, the
+@code{(gnu packages emacs)} module exports a variable named
+@code{emacs}, which is bound to a @code{<package>} object
+(@pxref{Defining Packages}).  The @code{(gnu packages)} module provides
+facilities for searching for packages.
+
+The distribution is fully @dfn{bootstrapped} and @dfn{self-contained}:
+each package is built based solely on other packages in the
+distribution.  The root of this dependency graph is a small set of
+@dfn{bootstrap binaries}, provided by the @code{(gnu packages
+bootstrap)} module.  These are statically-linked binaries of the core
+tools without which building anything at all would be impossible.
+
+
+Our goal is to build 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.
+
+Building this distribution is a cooperative effort, and you are invited
+to join!  Please get in touch with us on @email{bug-guix@@gnu.org}.  We
+welcome ideas, bug reports, patches, and anything that may be helpful to
+the project.
+
 
 @c *********************************************************************
 @node Acknowledgments