Merge pull request #2071 from sseefried-forked/clarify-glossary-and-garbage-collection

Add to glossary and clarify garbage collection
This commit is contained in:
Shea Levy 2018-04-12 06:12:38 -04:00 committed by GitHub
commit 3d748d3323
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 44 additions and 16 deletions

View file

@ -85,29 +85,48 @@
<glossentry xml:id="gloss-reference"><glossterm>reference</glossterm> <glossentry xml:id="gloss-reference"><glossterm>reference</glossterm>
<glossdef><para>A store path <varname>P</varname> is said to have a <glossdef>
reference to a store path <varname>Q</varname> if the store object <para>A store path <varname>P</varname> is said to have a
at <varname>P</varname> contains the path <varname>Q</varname> reference to a store path <varname>Q</varname> if the store object
somewhere. This implies than an execution involving at <varname>P</varname> contains the path <varname>Q</varname>
<varname>P</varname> potentially needs <varname>Q</varname> to be somewhere. The <emphasis>references</emphasis> of a store path are
present. The <emphasis>references</emphasis> of a store path are the set of store paths to which it has a reference.
the set of store paths to which it has a reference.</para></glossdef> </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>
<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> <glossentry xml:id="gloss-closure"><glossterm>closure</glossterm>
<glossdef><para>The closure of a store path is the set of store <glossdef><para>The closure of a store path is the set of store
paths that are directly or indirectly “reachable” from that store paths that are directly or indirectly “reachable” from that store
path; that is, its the closure of the path under the <link path; that is, its the closure of the path under the <link
linkend="gloss-reference">references</link> relation. For instance, linkend="gloss-reference">references</link> relation. For a package, the
if the store object at path <varname>P</varname> contains a closure of its derivation is equivalent to the build-time
reference to path <varname>Q</varname>, then <varname>Q</varname> is dependencies, while the closure of its output path is equivalent to its
in the closure of <varname>P</varname>. For correct deployment it runtime dependencies. For correct deployment it is necessary to deploy whole
is necessary to deploy whole closures, since otherwise at runtime closures, since otherwise at runtime files could be missing. The command
files could be missing. The command <command>nix-store <command>nix-store -qR</command> prints out closures of store paths.
-qR</command> prints out closures of store paths.</para></glossdef> </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>
@ -147,7 +166,7 @@
linkend="sec-profiles" />.</para> linkend="sec-profiles" />.</para>
</glossdef> </glossdef>
</glossentry> </glossentry>

View file

@ -60,7 +60,8 @@ This is because tools such as compilers dont search in per-packages
directories such as directories such as
<filename>/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include</filename>, <filename>/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include</filename>,
so if a package builds correctly on your system, this is because you so if a package builds correctly on your system, this is because you
specified the dependency explicitly.</para> specified the dependency explicitly. This takes care of the build-time
dependencies.</para>
<para>Once a package is built, runtime dependencies are found by <para>Once a package is built, runtime dependencies are found by
scanning binaries for the hash parts of Nix store paths (such as scanning binaries for the hash parts of Nix store paths (such as

View file

@ -52,6 +52,14 @@ garbage collector as follows:
<screen> <screen>
$ nix-store --gc</screen> $ nix-store --gc</screen>
The behaviour of the gargage collector is affected by the <literal>keep-
derivations</literal> (default: true) and <literal>keep-outputs</literal>
(default: false) options in the Nix configuration file. The defaults will ensure
that all derivations that are not build-time dependencies of garbage collector roots
will be collected but that all output paths that are not runtime dependencies
will be collected. (This is usually what you want, but while you are developing
it may make sense to keep outputs to ensure that rebuild times are quick.)
If you are feeling uncertain, you can also first view what files would If you are feeling uncertain, you can also first view what files would
be deleted: be deleted: