forked from lix-project/lix
676 lines
22 KiB
XML
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&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>
|