forked from lix-project/lix
Merge pull request #2071 from sseefried-forked/clarify-glossary-and-garbage-collection
Add to glossary and clarify garbage collection
This commit is contained in:
commit
3d748d3323
|
@ -85,29 +85,48 @@
|
|||
|
||||
<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. This implies than an execution involving
|
||||
<varname>P</varname> potentially needs <varname>Q</varname> to be
|
||||
present. The <emphasis>references</emphasis> of a store path are
|
||||
the set of store paths to which it has a reference.</para></glossdef>
|
||||
<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 instance,
|
||||
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>. 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></glossdef>
|
||||
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>
|
||||
|
||||
|
|
|
@ -60,7 +60,8 @@ This is because tools such as compilers don’t search in per-packages
|
|||
directories such as
|
||||
<filename>/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include</filename>,
|
||||
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
|
||||
scanning binaries for the hash parts of Nix store paths (such as
|
||||
|
|
|
@ -52,6 +52,14 @@ garbage collector as follows:
|
|||
<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
|
||||
be deleted:
|
||||
|
||||
|
|
Loading…
Reference in a new issue