summaryrefslogtreecommitdiff
path: root/doc/guix-cookbook.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/guix-cookbook.texi')
-rw-r--r--doc/guix-cookbook.texi40
1 files changed, 20 insertions, 20 deletions
diff --git a/doc/guix-cookbook.texi b/doc/guix-cookbook.texi
index 5d126acd3d..82700a48ad 100644
--- a/doc/guix-cookbook.texi
+++ b/doc/guix-cookbook.texi
@@ -581,7 +581,7 @@ packages.
Guix makes it possible to streamline the process by adding as many ``package
declaration directories'' as you want.
-Create a directory, say @samp{~./guix-packages} and add it to the @samp{GUIX_PACKAGE_PATH}
+Create a directory, say @file{~./guix-packages} and add it to the @samp{GUIX_PACKAGE_PATH}
environment variable:
@example
@@ -851,7 +851,7 @@ version when packaging programs for a specific commit.
@subsubsection Snippets
Snippets are quoted (i.e. non-evaluated) Scheme code that are a means of patching
-the source. They are a Guix-y alternative to the traditional @samp{.patch} files.
+the source. They are a Guix-y alternative to the traditional @file{.patch} files.
Because of the quote, the code in only evaluated when passed to the Guix daemon
for building. There can be as many snippets as needed.
@@ -955,7 +955,7 @@ $ make CC=gcc prefix=/gnu/store/...-<out>
This sets the C compiler to @code{gcc} and the @code{prefix} variable (the installation
directory in Make parlance) to @code{(assoc-ref %outputs "out")}, which is a build-stage
global variable pointing to the destination directory in the store (something like
-@samp{/gnu/store/...-my-libgit2-20180408}).
+@file{/gnu/store/...-my-libgit2-20180408}).
Similarly, it's possible to set the configure flags:
@@ -1080,7 +1080,7 @@ mechanism of passing code around two running processes is called @uref{https://a
@subsubsection Utility functions
When customizing @code{phases}, we often need to write code that mimics the
-equivalent system invocations (@code{make}, @code{mkdir}, @code{cp}, etc.) commonly used during
+equivalent system invocations (@code{make}, @code{mkdir}, @code{cp}, etc.)@: commonly used during
regular ``Unix-style'' installations.
Some like @code{chmod} are native to Guile.
@@ -1576,7 +1576,7 @@ available for inclusion into the initrd.
You could install StumpWM with a Guix system by adding
@code{stumpwm-checkout} and optionally @code{`(,stumpwm-checkout "lib")}
-packages to a system configuration file, e.g. @file{/etc/config.scm}.
+packages to a system configuration file, e.g.@: @file{/etc/config.scm}.
An example configuration can look like this:
@@ -1620,10 +1620,10 @@ Then you need to add the following code to a StumpWM configuration file
@section Setting up a bind mount
To bind mount a file system, one must first set up some definitions
-before the @code{operating-system} section of the system definition. In
+before the @code{operating-system} section of the system definition. In
this example we will bind mount a folder from a spinning disk drive to
-@code{/tmp}, to save wear and tear on the primary SSD, without
-dedicating an entire partition to be mounted as @code{/tmp}.
+@file{/tmp}, to save wear and tear on the primary SSD, without
+dedicating an entire partition to be mounted as @file{/tmp}.
First, the source drive that hosts the folder we wish to bind mount
should be defined, so that the bind mount can depend on it.
@@ -1791,8 +1791,8 @@ where we will store our profiles in the rest of this article.
Placing all your profiles in a single directory, with each profile getting its
own sub-directory, is somewhat cleaner. This way, each sub-directory will
-contain all the symlinks for precisely one profile. Besides, "looping over
-profiles" becomes obvious from any programming language (e.g. a shell script) by
+contain all the symlinks for precisely one profile. Besides, ``looping over
+profiles'' becomes obvious from any programming language (e.g.@: a shell script) by
simply looping over the sub-directories of @samp{$GUIX_EXTRA_PROFILES}.
Note that it's also possible to loop over the output of
@@ -1801,9 +1801,9 @@ Note that it's also possible to loop over the output of
guix package --list-profiles
@end example
-although you'll probably have to filter out @samp{~/.config/guix/current}.
+although you'll probably have to filter out @file{~/.config/guix/current}.
-To enable all profiles on login, add this to your @samp{~/.bash_profile} (or similar):
+To enable all profiles on login, add this to your @file{~/.bash_profile} (or similar):
@example
for i in $GUIX_EXTRA_PROFILES/*; do
@@ -1817,8 +1817,8 @@ done
@end example
Note to Guix System users: the above reflects how your default profile
-@samp{~/.guix-profile} is activated from @samp{/etc/profile}, that latter being loaded by
-@samp{~/.bashrc} by default.
+@file{~/.guix-profile} is activated from @file{/etc/profile}, that latter being loaded by
+@file{~/.bashrc} by default.
You can obviously choose to only enable a subset of them:
@@ -1861,8 +1861,8 @@ guix package -m /path/to/guix-my-project-manifest.scm -p "$GUIX_EXTRA_PROFILES"/
To upgrade all profiles, it's easy enough to loop over them. For instance,
assuming your manifest specifications are stored in
-@samp{~/.guix-manifests/guix-$profile-manifest.scm}, with @samp{$profile} being the name
-of the profile (e.g. "project1"), you could do the following in Bourne shell:
+@file{~/.guix-manifests/guix-$profile-manifest.scm}, with @samp{$profile} being the name
+of the profile (e.g.@: "project1"), you could do the following in Bourne shell:
@example
for profile in "$GUIX_EXTRA_PROFILES"/*; do
@@ -1921,12 +1921,12 @@ The same is true for @samp{INFOPATH} (you can install @samp{info-reader}),
@node Default profile
@subsection Default profile
-What about the default profile that Guix keeps in @samp{~/.guix-profile}?
+What about the default profile that Guix keeps in @file{~/.guix-profile}?
You can assign it the role you want. Typically you would install the manifest
of the packages you want to use all the time.
-Alternatively, you could keep it "manifest-less" for throw-away packages
+Alternatively, you could keep it ``manifest-less'' for throw-away packages
that you would just use for a couple of days.
This way makes it convenient to run
@@ -1957,7 +1957,7 @@ Manifests come with multiple benefits. In particular, they ease maintenance:
@itemize
@item
When a profile is set up from a manifest, the manifest itself is
-self-sufficient to keep a "package listing" around and reinstall the profile
+self-sufficient to keep a ``package listing'' around and reinstall the profile
later or on a different system. For ad-hoc profiles, we would need to
generate a manifest specification manually and maintain the package versions
for the packages that don't use the default version.
@@ -1994,7 +1994,7 @@ They can be manipulated in Scheme and passed to the various Guix @uref{https://e
It's important to understand that while manifests can be used to declare
profiles, they are not strictly equivalent: profiles have the side effect that
-they "pin" packages in the store, which prevents them from being
+they ``pin'' packages in the store, which prevents them from being
garbage-collected (@pxref{Invoking guix gc,,, guix, GNU Guix Reference Manual})
and ensures that they will still be available at any point in
the future.