2ef8f0608c
While trying to understand garbage collection it was not immediately clear that only the runtime dependency closure of output paths would be kept (instead of the build-time dependency closure). This commit attempts to clarify this by expanding some of the glossary definitions and extending the Garbage Collection section.
198 lines
6.5 KiB
XML
198 lines
6.5 KiB
XML
<appendix xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||
|
||
<title>Glossary</title>
|
||
|
||
|
||
<glosslist>
|
||
|
||
|
||
<glossentry xml:id="gloss-derivation"><glossterm>derivation</glossterm>
|
||
|
||
<glossdef><para>A description of a build action. The result of a
|
||
derivation is a store object. Derivations are typically specified
|
||
in Nix expressions using the <link
|
||
linkend="ssec-derivation"><function>derivation</function>
|
||
primitive</link>. These are translated into low-level
|
||
<emphasis>store derivations</emphasis> (implicitly by
|
||
<command>nix-env</command> and <command>nix-build</command>, or
|
||
explicitly by <command>nix-instantiate</command>).</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry><glossterm>store</glossterm>
|
||
|
||
<glossdef><para>The location in the file system where store objects
|
||
live. Typically <filename>/nix/store</filename>.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry><glossterm>store path</glossterm>
|
||
|
||
<glossdef><para>The location in the file system of a store object,
|
||
i.e., an immediate child of the Nix store
|
||
directory.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry><glossterm>store object</glossterm>
|
||
|
||
<glossdef><para>A file that is an immediate child of the Nix store
|
||
directory. These can be regular files, but also entire directory
|
||
trees. Store objects can be sources (objects copied from outside of
|
||
the store), derivation outputs (objects produced by running a build
|
||
action), or derivations (files describing a build
|
||
action).</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-substitute"><glossterm>substitute</glossterm>
|
||
|
||
<glossdef><para>A substitute is a command invocation stored in the
|
||
Nix database that describes how to build a store object, bypassing
|
||
the normal build mechanism (i.e., derivations). Typically, the
|
||
substitute builds the store object by downloading a pre-built
|
||
version of the store object from some server.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry><glossterm>purity</glossterm>
|
||
|
||
<glossdef><para>The assumption that equal Nix derivations when run
|
||
always produce the same output. This cannot be guaranteed in
|
||
general (e.g., a builder can rely on external inputs such as the
|
||
network or the system time) but the Nix model assumes
|
||
it.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry><glossterm>Nix expression</glossterm>
|
||
|
||
<glossdef><para>A high-level description of software packages and
|
||
compositions thereof. Deploying software using Nix entails writing
|
||
Nix expressions for your packages. Nix expressions are translated
|
||
to derivations that are stored in the Nix store. These derivations
|
||
can then be built.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-reference"><glossterm>reference</glossterm>
|
||
|
||
<glossdef>
|
||
<para>A store path <varname>P</varname> is said to have a
|
||
reference to a store path <varname>Q</varname> if the store object
|
||
at <varname>P</varname> contains the path <varname>Q</varname>
|
||
somewhere. The <emphasis>references</emphasis> of a store path are
|
||
the set of store paths to which it has a reference.
|
||
</para>
|
||
<para>A derivation can reference other derivations and sources
|
||
(but not output paths), whereas an output path only references other
|
||
output paths.
|
||
</para>
|
||
</glossdef>
|
||
|
||
</glossentry>
|
||
|
||
<glossentry xml:id="gloss-reachable"><glossterm>reachable</glossterm>
|
||
|
||
<glossdef><para>A store path <varname>Q</varname> is reachable from
|
||
another store path <varname>P</varname> if <varname>Q</varname> is in the
|
||
<link linked="gloss-closure">closure</link> of the
|
||
<link linkend="gloss-reference">references</link> relation.
|
||
</para></glossdef>
|
||
</glossentry>
|
||
|
||
<glossentry xml:id="gloss-closure"><glossterm>closure</glossterm>
|
||
|
||
<glossdef><para>The closure of a store path is the set of store
|
||
paths that are directly or indirectly “reachable” from that store
|
||
path; that is, it’s the closure of the path under the <link
|
||
linkend="gloss-reference">references</link> relation. For a package, the
|
||
closure of its derivation is equivalent to the build-time
|
||
dependencies, while the closure of its output path is equivalent to its
|
||
runtime dependencies. For correct deployment it is necessary to deploy whole
|
||
closures, since otherwise at runtime files could be missing. The command
|
||
<command>nix-store -qR</command> prints out closures of store paths.
|
||
</para>
|
||
<para>As an example, if the store object at path <varname>P</varname> contains
|
||
a reference to path <varname>Q</varname>, then <varname>Q</varname> is
|
||
in the closure of <varname>P</varname>. Further, if <varname>Q</varname>
|
||
references <varname>R</varname> then <varname>R</varname> is also in
|
||
the closure of <varname>P</varname>.
|
||
</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-output-path"><glossterm>output path</glossterm>
|
||
|
||
<glossdef><para>A store path produced by a derivation.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-deriver"><glossterm>deriver</glossterm>
|
||
|
||
<glossdef><para>The deriver of an <link
|
||
linkend="gloss-output-path">output path</link> is the store
|
||
derivation that built it.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-validity"><glossterm>validity</glossterm>
|
||
|
||
<glossdef><para>A store path is considered
|
||
<emphasis>valid</emphasis> if it exists in the file system, is
|
||
listed in the Nix database as being valid, and if all paths in its
|
||
closure are also valid.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-user-env"><glossterm>user environment</glossterm>
|
||
|
||
<glossdef><para>An automatically generated store object that
|
||
consists of a set of symlinks to “active” applications, i.e., other
|
||
store paths. These are generated automatically by <link
|
||
linkend="sec-nix-env"><command>nix-env</command></link>. See <xref
|
||
linkend="sec-profiles" />.</para>
|
||
|
||
</glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-profile"><glossterm>profile</glossterm>
|
||
|
||
<glossdef><para>A symlink to the current <link
|
||
linkend="gloss-user-env">user environment</link> of a user, e.g.,
|
||
<filename>/nix/var/nix/profiles/default</filename>.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
<glossentry xml:id="gloss-nar"><glossterm>NAR</glossterm>
|
||
|
||
<glossdef><para>A <emphasis>N</emphasis>ix
|
||
<emphasis>AR</emphasis>chive. This is a serialisation of a path in
|
||
the Nix store. It can contain regular files, directories and
|
||
symbolic links. NARs are generated and unpacked using
|
||
<command>nix-store --dump</command> and <command>nix-store
|
||
--restore</command>.</para></glossdef>
|
||
|
||
</glossentry>
|
||
|
||
|
||
|
||
</glosslist>
|
||
|
||
|
||
</appendix>
|