lix/doc/manual/nix-store.xml
2005-04-10 20:54:21 +00:00

676 lines
22 KiB
XML

<refentry>
<refnamediv>
<refname>nix-store</refname>
<refpurpose>manipulate or query the Nix store</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>nix-store</command>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="opt-common-syn.xml#xpointer(/nop/*)" />
<arg><option>--add-root</option> <replaceable>path</replaceable></arg>
<arg><option>--indirect</option></arg>
<arg choice='plain'><replaceable>operation</replaceable></arg>
<arg rep='repeat'><replaceable>options</replaceable></arg>
<arg rep='repeat'><replaceable>arguments</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsection><title>Description</title>
<para>The command <command>nix-store</command> performs primitive
operations on the Nix store. You generally do not need to run this
command manually.</para>
<para><command>nix-store</command> takes exactly one
<emphasis>operation</emphasis> flag which indicates the subcommand to
be performed. These are documented below.</para>
</refsection>
<!--######################################################################-->
<refsection><title>Common options</title>
<para>This section lists the options that are common to all
operations. These options are allowed for every subcommand, though
they may not always have an effect. See also <xref
linkend="sec-common-options" /> for a list of common options.</para>
<variablelist>
<varlistentry id="opt-add-root"><term><option>--add-root</option> <replaceable>path</replaceable></term>
<listitem><para>Causes the result of a realisation
(<option>--realise</option> and <option>--force-realise</option>)
to be registered as a root of the garbage collector (see <xref
linkend="ssec-gc-roots" />). The root is stored in
<replaceable>path</replaceable>, which must be inside a directory
that is scanned for roots by the garbage collector (i.e.,
typically in a subdirectory of
<filename>/nix/var/nix/gcroots/</filename>)
<emphasis>unless</emphasis> the <option>--indirect</option> flag
is used.</para>
<para>If there are multiple results, then multiple symlinks will
be created by sequentially numbering symlinks beyond the first one
(e.g., <filename>foo</filename>, <filename>foo-2</filename>,
<filename>foo-3</filename>, and so on).</para></listitem>
</varlistentry>
<varlistentry><term><option>--indirect</option></term>
<listitem>
<para>In conjunction with <option>--add-root</option>, this option
allows roots to be stored <emphasis>outside</emphasis> of the GC
roots directory. This is useful for commands such as
<command>nix-build</command> that place a symlink to the build
result in the current directory; such a build result should not be
garbage-collected unless the symlink is removed.</para>
<para>The <option>--indirect</option> flag causes a uniquely named
symlink to <replaceable>path</replaceable> to be stored in
<filename>/nix/var/nix/gcroots/auto/</filename>. For instance,
<screen>
$ nix-store --add-root /home/eelco/bla/result --indirect -r <replaceable>...</replaceable>
$ ls -l /nix/var/nix/gcroots/auto
lrwxrwxrwx 1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result
$ ls -l /home/eelco/bla/result
lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10</screen>
Thus, when <filename>/home/eelco/bla/result</filename> is removed,
the GC root in the <filename>auto</filename> directory becomes a
dangling symlink and will be ignored by the collector.</para>
<warning><para>Note that it is not possible to move or rename
indirect GC roots, since the symlink in the
<filename>auto</filename> directory will still point to the old
location.</para></warning>
</listitem>
</varlistentry>
</variablelist>
</refsection>
<!--######################################################################-->
<refsection id='rsec-nix-store-realise'><title>Operation
<option>--realise</option></title>
<refsection><title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<group choice='req'>
<arg choice='plain'><option>--realise</option></arg>
<arg choice='plain'><option>-r</option></arg>
</group>
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>The operation <option>--realise</option> essentially “builds”
the specified store paths. Realisation is a somewhat overloaded term:
<itemizedlist>
<listitem><para>If the store path is a
<emphasis>derivation</emphasis>, realisation ensures that the output
paths of the derivation are <link
linkend="gloss-validity">valid</link> (i.e., the output path and its
closure exist in the file system). This can be done in several
ways. First, it is possible that the outputs are already valid, in
which case we are done immediately. Otherwise, there may be <link
linkend="gloss-substitute">substitutes</link> that produce the
outputs (e.g., by downloading them). Finally, the outputs can be
produced by performing the build action described by the
derivation.</para></listitem>
<listitem><para>If the store path is not a derivation, realisation
ensures that the specified path is valid (i.e., it and its closure
exist in the file system). If the path is already valid, we are
done immediately. Otherwise, the path and any missing paths in its
closure may be produced through substitutes. If there are no
(succesful) subsitutes, realisation fails.</para></listitem>
</itemizedlist>
</para>
<para>The output path of each derivation is printed on standard
output. (For non-derivations argument, the argument itself is
printed.)</para>
</refsection>
<refsection><title>Examples</title>
<para>This operation is typically used to build store derivations
produced by <link
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>:
<screen>
$ nix-store -r $(nix-instantiate ./test.nix)
/nix/store/31axcgrlbfsxzmfff1gyj1bf62hvkby2-aterm-2.3.1</screen>
This is essentially what <link
linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
</refsection>
</refsection>
<!--######################################################################-->
<refsection id='rsec-nix-store-gc'><title>Operation <option>--gc</option></title>
<refsection><title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<arg choice='plain'><option>--gc</option></arg>
<group>
<arg choice='plain'><option>--print-roots</option></arg>
<arg choice='plain'><option>--print-live</option></arg>
<arg choice='plain'><option>--print-dead</option></arg>
<arg choice='plain'><option>--delete</option></arg>
</group>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>Without additional flags, the operation <option>--gc</option>
performs a garbage collection on the Nix store. That is, all paths in
the Nix store not reachable via file system references from a set of
“roots”, are deleted.</para>
<para>The following suboperations may be specified:</para>
<variablelist>
<varlistentry><term><option>--print-roots</option></term>
<listitem><para>This operation prints on standard output the set
of roots used by the garbage collector. What constitutes a root
is described in <xref linkend="ssec-gc-roots"
/>.</para></listitem>
</varlistentry>
<varlistentry><term><option>--print-live</option></term>
<listitem><para>This operation prints on standard output the set
of “live” store paths, which are all the store paths reachable
from the roots. Live paths should never be deleted, since that
would break consistency — it would become possible that
applications are installed that reference things that are no
longer present in the store.</para></listitem>
</varlistentry>
<varlistentry><term><option>--print-dead</option></term>
<listitem><para>This operation prints out on standard output the
set of “dead” store paths, which is just the opposite of the set
of live paths: any path in the store that is not live (with
respect to the roots) is dead.</para></listitem>
</varlistentry>
<varlistentry><term><option>--delete</option></term>
<listitem><para>This operation performs an actual garbage
collection. All dead paths are removed from the
store. This is the default.</para></listitem>
</varlistentry>
</variablelist>
<para>The behaviour of the collector is influenced by the <link
linkend="conf-gc-keep-outputs"><literal>gc-keep-outputs</literal></link>
and <link
linkend="conf-gc-keep-derivations"><literal>gc-keep-derivations</literal></link>
variables in the Nix configuration file.</para>
</refsection>
<refsection><title>Examples</title>
<para>To delete all unreachable paths, just do:
<screen>
$ nix-store --gc</screen>
</para>
</refsection>
</refsection>
<!--######################################################################-->
<refsection><title>Operation <option>--query</option></title>
<refsection><title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<group choice='req'>
<arg choice='plain'><option>--query</option></arg>
<arg choice='plain'><option>-q</option></arg>
</group>
<group choice='req'>
<arg choice='plain'><option>--outputs</option></arg>
<arg choice='plain'><option>--requisites</option></arg>
<arg choice='plain'><option>-R</option></arg>
<arg choice='plain'><option>--references</option></arg>
<arg choice='plain'><option>--referers</option></arg>
<arg choice='plain'><option>--referers-closure</option></arg>
<arg choice='plain'><option>--deriver</option></arg>
<arg choice='plain'><option>--deriver</option></arg>
<arg choice='plain'><option>--graph</option></arg>
<arg choice='plain'><option>--tree</option></arg>
<arg choice='plain'><option>--binding</option> <replaceable>name</replaceable></arg>
<arg choice='plain'><option>--hash</option></arg>
</group>
<arg><option>--use-output</option></arg>
<arg><option>-u</option></arg>
<arg><option>--force-realise</option></arg>
<arg><option>-f</option></arg>
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>The operation <option>--query</option> displays various bits of
information about the store paths . The queries are described below. At
most one query can be specified. The default query is
<option>--outputs</option>.</para>
<para>The paths <replaceable>paths</replaceable> may also be symlinks
from outside of the Nix store, to the Nix store. In that case, the
query is applied to the target of the symlink.</para>
</refsection>
<refsection><title>Common query options</title>
<variablelist>
<varlistentry><term><option>--use-output</option></term>
<term><option>-u</option></term>
<listitem><para>For each argument to the query that is a store
derivation, apply the query to the output path of the derivation
instead.</para></listitem>
</varlistentry>
<varlistentry><term><option>--force-realise</option></term>
<term><option>-f</option></term>
<listitem><para>Realise each argument to the query first (see
<link linkend="rsec-nix-store-realise"><command>nix-store
--realise</command></link>).</para></listitem>
</varlistentry>
</variablelist>
</refsection>
<refsection id='nixref-queries'><title>Queries</title>
<variablelist>
<varlistentry><term><option>--outputs</option></term>
<listitem><para>Prints out the <link
linkend="gloss-output-path">output paths</link> of the store
derivations <replaceable>paths</replaceable>. These are the paths
that will be produced when the derivation is
built.</para></listitem>
</varlistentry>
<varlistentry><term><option>--requisites</option></term>
<term><option>-R</option></term>
<listitem><para>Prints out the <link
linkend="gloss-closure">closure</link> of the store path
<replaceable>paths</replaceable>.</para>
<para>This query has one option:</para>
<variablelist>
<varlistentry><term><option>--include-outputs</option></term>
<listitem><para>Also include the output path of store
derivations, and their closures.</para></listitem>
</varlistentry>
</variablelist>
<para>This query can be used to implement various kinds of
deployment. A <emphasis>source deployment</emphasis> is obtained
by distributing the closure of a store derivation. A
<emphasis>binary deployment</emphasis> is obtained by distributing
the closure of an output path. A <emphasis>cache
deployment</emphasis> (combined source/binary deployment,
including binaries of build-time-only dependencies) is obtained by
distributing the closure of a store derivation and specifying the
option <option>--include-outputs</option>.</para>
</listitem>
</varlistentry>
<varlistentry><term><option>--references</option></term>
<listitem><para>Prints the set of <link
linkend="gloss-reference">references</link> of the store paths
<replaceable>paths</replaceable>, that is, their immediate
dependencies. (For <emphasis>all</emphasis> dependencies, use
<option>--requisites</option>.)</para></listitem>
</varlistentry>
<varlistentry><term><option>--referers</option></term>
<listitem><para>Prints the set of <emphasis>referers</emphasis> of
the store paths <replaceable>paths</replaceable>, that is, the
store paths currently existing in the Nix store that refer to one
of <replaceable>paths</replaceable>. Note that contrary to the
references, the set of referers is not constant; it can change as
store paths are added or removed.</para></listitem>
</varlistentry>
<varlistentry><term><option>--referers-closure</option></term>
<listitem><para>Prints the closure of the set of store paths
<replaceable>paths</replaceable> under the referers relation; that
is, all store paths that directly or indirectly refer to one of
<replaceable>paths</replaceable>. These are all the path currently
in the Nix store that are dependent on
<replaceable>paths</replaceable>.</para></listitem>
</varlistentry>
<varlistentry><term><option>--deriver</option></term>
<listitem><para>Prints the <link
linkend="gloss-deriver">deriver</link> of the store paths
<replaceable>paths</replaceable>. If the path has no deriver
(e.g., if it is a source file), or if the deriver is not known
(e.g., in the case of a binary-only deployment), the string
<literal>unknown-deriver</literal> is printed.</para></listitem>
</varlistentry>
<varlistentry><term><option>--graph</option></term>
<listitem><para>Prints the references graph of the store paths
<replaceable>paths</replaceable> in the format of the
<command>dot</command> tool of AT&amp;T's <ulink
url="http://www.graphviz.org/">Graphviz package</ulink>. This can
be used to visualise dependency graphs. To obtain a build-time
dependency graph, apply this to a store derivation. To obtain a
runtime dependency graph, apply it to an output
path.</para></listitem>
</varlistentry>
<varlistentry><term><option>--tree</option></term>
<listitem><para>Prints the references graph of the store paths
<replaceable>paths</replaceable> as a nested ASCII tree.
References are ordered by descending closure size; this tends to
flatten the tree, making it more readable. The query only
recurses into a store path when it is first encountered; this
prevents a blowup of the tree representation of the
graph.</para></listitem>
</varlistentry>
<varlistentry><term><option>--binding</option> <replaceable>name</replaceable></term>
<listitem><para>Prints the value of the attribute
<replaceable>name</replaceable> (i.e., environment variable) of
the store derivations <replaceable>paths</replaceable>. It is an
error for a derivation to not have the specified
attribute.</para></listitem>
</varlistentry>
<varlistentry><term><option>--hash</option></term>
<listitem><para>Prints the SHA-256 hash of the contents of the
store path <replaceable>paths</replaceable>. Since the hash is
stored in the Nix database, this is a fast
operation.</para></listitem>
</varlistentry>
</variablelist>
</refsection>
<refsection><title>Examples</title>
<para>Print the closure (runtime dependencies) of the
<command>svn</command> program in the current user environment:
<screen>
$ nix-store -qR $(which svn)
/nix/store/4mbglq5ldqld8sj57273aljwkfvj22mc-subversion-1.1.4
/nix/store/8lz9yc6zgmc0vlqmn2ipcpkjlmbi51vv-glibc-2.3.4
<replaceable>...</replaceable></screen>
</para>
<para>Print the build-time dependencies of <command>svn</command>:
<screen>
$ nix-store -qR $(nix-store -qd $(which svn))
/nix/store/02iizgn86m42q905rddvg4ja975bk2i4-grep-2.5.1.tar.bz2.drv
/nix/store/07a2bzxmzwz5hp58nf03pahrv2ygwgs3-gcc-wrapper.sh
/nix/store/0ma7c9wsbaxahwwl04gbw3fcd806ski4-glibc-2.3.4.drv
<replaceable>... lots of other paths ...</replaceable></screen>
The difference with the previous example is that we ask the closure of
the derivation (<option>-qd</option>), not the closure of the output
path that contains <command>svn</command>.</para>
<para>Show the build-time dependencies as a tree:
<screen>
$ nix-store -q --tree $(nix-store -qd $(which svn))
/nix/store/7i5082kfb6yjbqdbiwdhhza0am2xvh6c-subversion-1.1.4.drv
+---/nix/store/d8afh10z72n8l1cr5w42366abiblgn54-builder.sh
+---/nix/store/fmzxmpjx2lh849ph0l36snfj9zdibw67-bash-3.0.drv
| +---/nix/store/570hmhmx3v57605cqg9yfvvyh0nnb8k8-bash
| +---/nix/store/p3srsbd8dx44v2pg6nbnszab5mcwx03v-builder.sh
<replaceable>...</replaceable></screen>
</para>
<para>Show all paths that depend on the same OpenSSL library as
<command>svn</command>:
<screen>
$ nix-store -q --referers $(nix-store -q --binding openssl $(nix-store -qd $(which svn)))
/nix/store/23ny9l9wixx21632y2wi4p585qhva1q8-sylpheed-1.0.0
/nix/store/4mbglq5ldqld8sj57273aljwkfvj22mc-subversion-1.1.4
/nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3
/nix/store/l51240xqsgg8a7yrbqdx1rfzyv6l26fx-lynx-2.8.5</screen>
</para>
<para>Show all paths that directly or indirectly depend on the Glibc
(C library) used by <command>svn</command>:
<screen>
$ nix-store -q --referers-closure $(ldd $(which svn) | grep /libc.so | awk '{print $3}')
/nix/store/034a6h4vpz9kds5r6kzb9lhh81mscw43-libgnomeprintui-2.8.2
/nix/store/05l3yi0d45prm7a82pcrknxdh6nzmxza-gawk-3.1.4
<replaceable>...</replaceable></screen>
Note that <command>ldd</command> is a command that prints out the
dynamic libraries used by an ELF executable.</para>
<para>Make a picture of the runtime dependency graph of the current
user environment:
<screen>
$ nix-store -q --graph ~/.nix-profile | dot -Tps > graph.ps
$ gv graph.ps</screen>
</para>
</refsection>
</refsection>
<!--######################################################################-->
<!--
<refsection id="rsec-nix-store-reg-val"><title>Operation <option>-XXX-register-validity</option></title>
<refsection><title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<arg choice='plain'><option>-XXX-register-validity</option></arg>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>TODO</para>
</refsection>
</refsection>
-->
<!--######################################################################-->
<!--
<refsection><title>Operation <option>-XXX-substitute</option></title>
<refsection><title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<arg choice='plain'><option>-XXX-substitute</option></arg>
<arg choice='plain'
rep='repeat'><replaceable>srcpath</replaceable> <replaceable>subpath</replaceable></arg>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>The operation <option>-XXX-substitute</option> registers that the
store path <replaceable>srcpath</replaceable> can be built by
realising the derivation expression in
<replaceable>subpath</replaceable>. This is used to implement binary
deployment.</para>
</refsection>
</refsection>
-->
<!--######################################################################-->
<refsection><title>Operation <option>--verify</option></title>
<refsection>
<title>Synopsis</title>
<cmdsynopsis>
<command>nix-store</command>
<arg choice='plain'><option>--verify</option></arg>
<arg><option>--check-contents</option></arg>
</cmdsynopsis>
</refsection>
<refsection><title>Description</title>
<para>The operation <option>--verify</option> verifies the internal
consistency of the Nix database, and the consistency between the Nix
database and the Nix store. Any inconsistencies encountered are
automatically repaired. Inconsistencies are generally the result of
the Nix store or database being modified by non-Nix tools, or of bugs
in Nix itself.</para>
<para>There is one option:
<variablelist>
<varlistentry><term><option>--check-contents</option></term>
<listitem><para>Checks that the contents of every valid store path
has not been altered by computing a SHA-256 hash of the contents
and comparing it with the hash stored in the Nix database at build
time. Paths that have been modified are printed out. For large
stores, <option>--check-contents</option> is obviously quite
slow.</para></listitem>
</varlistentry>
</variablelist>
</para>
</refsection>
</refsection>
</refentry>