Add to glossary and clarify garbage collection

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.

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
+  <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 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,
+  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>
 
@@ -147,7 +166,7 @@
   linkend="sec-profiles" />.</para>
 
   </glossdef>
-  
+
 </glossentry>
 
 

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

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: