> But anyway, the normal way to use Texinfo is like TeX: you use ASCII > quotes, and it does the right thing (see the PDF output, and the Info > output if you’re using makeinfo 5.x.)
I know, I was talking about the output of 'makeinfo --html'. I'm using 4.13. > There seems to be some paragraph filling at least here. Yes, I did that to keep the length under 79 characters and to avoid the lines which consist of a couple of words. > Could you rearrange the patch to avoid paragraph filling, so that only > the parts that were really changed show up? Is it OK?
From 91df1e8c54d824807a1681b381e76cf25d40538a Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov <[email protected]> Date: Sat, 25 May 2013 00:04:00 +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 | 50 +++++++++++++++++++++++++------------------------- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index cf54fe4..28b8d84 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -96,42 +96,41 @@ 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, +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 +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 a given set of inputs. Last -but not least, a build function cannot alter the system's environment in +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 dedicated ``chroots'', where only their explicit -inputs are visible. +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 +Store}). Each installed package has its own directory there. +The directory name contains +a hash of all build inputs of 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 +174,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 +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, -@url{http://nixos.org/nix/, Nix} replaces the three dependencies above. +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
pgpz1zpxe7BV9.pgp
Description: PGP signature
