max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-22 22:16:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add to glossary and clarify garbage collection

Browse source 
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.
This commit is contained in:
Sean Seefried 2018-04-12 19:23:24 +10:00
parent dc0a542c9f
commit 2ef8f0608c
3 changed files with 44 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
doc/manual/glossary/glossary.xml
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, it’s the closure of the path under the <link path; that is, it’s 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>

3
doc/manual/introduction/about-nix.xml
View file

@ -60,7 +60,8 @@ This is because tools such as compilers don’t 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

8
doc/manual/packages/garbage-collection.xml
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: