From 3384e3e2e00d3cbef37b913c9a17df5842522ef8 Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov Date: Fri, 24 May 2013 12:02:15 +0000 Subject: [PATCH] doc: Improve wording and fix typos in "Introduction" and "Requirements". * doc/guix.texi (Introduction, Requirements): Rephrase and fix typos. --- doc/guix.texi | 66 +++++++++++++++++++++++++++----------------------------- 1 files changed, 32 insertions(+), 34 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index c3aab81..9a12ff9 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -96,42 +96,39 @@ Documentation License.'' GNU Guix@footnote{``Guix'' is pronounced like ``geeks'', or ``ɡiːks'' using the international phonetic alphabet (IPA).} is a functional package management tool for the GNU system. Package management consists -in all the activities that relate to building packages from source, -honoring the build-time and run-time dependencies on packages, -installing packages in user environments, upgrading installed packages -to new versions or rolling back to a previous set, removing unused -software packages, etc. +of all activities that relate to building packages from sources, +preserving their build-time and run-time dependencies, installing +packages in user environments, upgrading installed packages to new +versions or rolling back to a previous set, removing unused software +packages, etc. @cindex functional package management -The term @dfn{functional} refers to a specific package management -discipline. In Guix, the package build and installation process is seen -as a function, in the mathematical sense: that function takes inputs, -such as build scripts, a compiler, and libraries depended on, and -returns the 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. Last -but not least, a build function cannot alter the system's environment 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 dedicated ``chroots'', where only their explicit -inputs are visible. +The term @dfn{functional} refers to a specific set of package management +features. In Guix, the package build and installation process is seen +as a function, in the mathematical sense. That function takes inputs, +such as build scripts, a compiler, and libraries, and returns an +installed package. As a pure function, its result depends solely on its +inputs---for instance, it cannot refer to software or scripts that were +not explicitly passed as inputs. A build function always produces the +same result when passed the same set of inputs. It cannot alter the +system's environment 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{chroots}), where only their explicit inputs are visible. @cindex store -The result of package build functions is @dfn{cached} in the file +The result of package's 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---by default under @file{/nix/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. +Store}). Each installed package has its own directory there. 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 upgrades and rollback, per-user installation, and +transactional package upgrades and rollbacks, per-user installation, and garbage collection of packages (@pxref{Features}). -Guix has a command-line interface allowing users to build, install, +Guix has a command-line interface which allows 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 @@ -175,19 +172,20 @@ following packages are also needed: @item @url{http://gcc.gnu.org, GCC's g++} @end itemize -When a working installation of the Nix package manager is available, you -can instead configure Guix with @code{--disable-daemon}. In that case, -@url{http://nixos.org/nix/, Nix} replaces the three dependencies above. +When a working installation of @url{http://nixos.org/nix/, the Nix +package manager} is available, you can instead configure Guix with +@code{--disable-daemon}. In that case, Nix replaces the three +dependencies above. Guix is compatible with Nix, so it is possible to share the same store between both. To do so, you must pass @command{configure} not only the same @code{--with-store-dir} value, but also the same -@code{--localstatedir} value (the latter is essential because it -specifies where the database that store meta-data about the store is -located, among other things.) The default values are +@code{--localstatedir} value. The latter is essential because it +specifies where the database that stores metadata about the store is +located, among other things. The default values are @code{--with-store-dir=/nix/store} and @code{--localstatedir=/nix/var}. -Note that @code{--disable-daemon} is orthogonal and is not required if -your goal is to share the same store as Nix. +Note that @code{--disable-daemon} is not required if your goal is to +share the store with Nix. @node Setting Up the Daemon @section Setting Up the Daemon -- 1.7.5.4