diff options
author | Shea Levy <shea@shealevy.com> | 2018-04-12T10·12-0400 |
---|---|---|
committer | GitHub <noreply@github.com> | 2018-04-12T10·12-0400 |
commit | 3d748d3323abe1d5f2787b1f9a64eb453a918d0e (patch) | |
tree | 7eb49aa898dbec9f21d052da4da08003cd06c1e1 /doc | |
parent | dc0a542c9f8c839b8437b54fcf1c4b47b0cfba10 (diff) | |
parent | 2ef8f0608caa27d1a92d827f54b54155c89092a8 (diff) |
Merge pull request #2071 from sseefried-forked/clarify-glossary-and-garbage-collection
Add to glossary and clarify garbage collection
Diffstat (limited to 'doc')
-rw-r--r-- | doc/manual/glossary/glossary.xml | 49 | ||||
-rw-r--r-- | doc/manual/introduction/about-nix.xml | 3 | ||||
-rw-r--r-- | doc/manual/packages/garbage-collection.xml | 8 |
3 files changed, 44 insertions, 16 deletions
diff --git a/doc/manual/glossary/glossary.xml b/doc/manual/glossary/glossary.xml index e0636044cc25..a13630d2a4e9 100644 --- a/doc/manual/glossary/glossary.xml +++ b/doc/manual/glossary/glossary.xml @@ -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> @@ -147,7 +166,7 @@ linkend="sec-profiles" />.</para> </glossdef> - + </glossentry> diff --git a/doc/manual/introduction/about-nix.xml b/doc/manual/introduction/about-nix.xml index 83a2b6786ac0..e8c0a29753a1 100644 --- a/doc/manual/introduction/about-nix.xml +++ b/doc/manual/introduction/about-nix.xml @@ -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 diff --git a/doc/manual/packages/garbage-collection.xml b/doc/manual/packages/garbage-collection.xml index 03b8e4c976c1..a1b0ef22a11e 100644 --- a/doc/manual/packages/garbage-collection.xml +++ b/doc/manual/packages/garbage-collection.xml @@ -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: |