* Lots of manual updates, in particular the new `nix-store --query'
options were documented, as well as the Nix configuration file.
This commit is contained in:
Eelco Dolstra
parent
4271385a73
commit
8b70f138e0
11 changed files with 462 additions and 174 deletions
|
|
@ -20,6 +20,7 @@ MANUAL_SRCS = manual.xml introduction.xml installation.xml \
|
||||||
$(man1_MANS:.1=.xml) \
|
$(man1_MANS:.1=.xml) \
|
||||||
troubleshooting.xml bugs.xml opt-common.xml opt-common-syn.xml \
|
troubleshooting.xml bugs.xml opt-common.xml opt-common-syn.xml \
|
||||||
env-common.xml quick-start.xml nix-lang-ref.xml glossary.xml \
|
env-common.xml quick-start.xml nix-lang-ref.xml glossary.xml \
|
||||||
|
conf-file.xml \
|
||||||
style.css images
|
style.css images
|
||||||
|
|
||||||
manual.is-valid: $(MANUAL_SRCS) version.txt
|
manual.is-valid: $(MANUAL_SRCS) version.txt
|
||||||
|
|
|
||||||
|
|
@ -2,36 +2,25 @@
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
|
|
||||||
<listitem>
|
<listitem><para>The man-pages generated from the DocBook documentation
|
||||||
<para>
|
are ugly.</para></listitem>
|
||||||
The man-pages generated from the DocBook documentation are ugly.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
<listitem><para>Generations properly form a tree. E.g., if after
|
||||||
<para>
|
switching to generation 39, we perform an installation action, a
|
||||||
Generations properly form a tree. E.g., if after switching to
|
generation 43 is created which is a descendant of 39, not 42. So a
|
||||||
generation 39, we perform an installation action, a generation
|
rollback from 43 ought to go back to 39. This is not currently
|
||||||
43 is created which is a descendant of 39, not 42. So a
|
implemented; generations form a linear sequence.</para></listitem>
|
||||||
rollback from 43 ought to go back to 39. This is not
|
|
||||||
currently implemented; generations form a linear sequence.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
<listitem><para><emphasis>Build management.</emphasis> In principle it
|
||||||
<para>
|
is already possible to do build management using Nix (by writing
|
||||||
<emphasis>Build management.</emphasis> In principle it is already
|
builders that perform appropriate build steps), but the Nix expression
|
||||||
possible to do build management using Nix (by writing builders that
|
language is not yet powerful enough to make this pleasant (?). The
|
||||||
perform appropriate build steps), but the Nix expression language is
|
language should be extended with features from the <ulink
|
||||||
not yet powerful enough to make this pleasant (?). The language should
|
url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>.
|
||||||
be extended with features from the <ulink
|
Another interesting idea is to write a <command>make</command>
|
||||||
url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>.
|
implementation that uses Nix as a back-end to support <ulink
|
||||||
Another interesting idea is to write a <command>make</command>
|
url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
|
||||||
implementation that uses Nix as a back-end to support <ulink
|
build files.</para></listitem>
|
||||||
url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
|
|
||||||
build files.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem><para>For security, <command>nix-push</command> manifests
|
<listitem><para>For security, <command>nix-push</command> manifests
|
||||||
should be digitally signed, and <command>nix-pull</command> should
|
should be digitally signed, and <command>nix-pull</command> should
|
||||||
|
|
@ -44,6 +33,14 @@ them).</para></listitem>
|
||||||
<command>nix-env --delete-generations</command> to remove non-current
|
<command>nix-env --delete-generations</command> to remove non-current
|
||||||
generations older than a certain age.</para></listitem>
|
generations older than a certain age.</para></listitem>
|
||||||
|
|
||||||
|
<listitem><para>There should be a flexible way to change the user
|
||||||
|
environment builder. Currently, you have to replace
|
||||||
|
<filename><replaceable>prefix</replaceable>/share/nix/corepkgs/buildenv/builder.pl</filename>,
|
||||||
|
which is hard-coded into <command>nix-env</command>. Also, the
|
||||||
|
default builder should be more powerful. For instance, there should
|
||||||
|
be some way to specify priorities to resolve
|
||||||
|
collisions.</para></listitem>
|
||||||
|
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
</appendix>
|
</appendix>
|
||||||
|
|
|
||||||
82
doc/manual/conf-file.xml
Normal file
82
doc/manual/conf-file.xml
Normal file
|
|
@ -0,0 +1,82 @@
|
||||||
|
<sect1 id="sec-conf-file"><title>Nix configuration file</title>
|
||||||
|
|
||||||
|
<para>A number of persistent settings of Nix are stored in the file
|
||||||
|
<filename><replaceable>prefix</replaceable>/etc/nix/nix.conf</filename>.
|
||||||
|
This file is a list of <literal><replaceable>name</replaceable> =
|
||||||
|
<replaceable>value</replaceable></literal> pairs, one per line.
|
||||||
|
Comments start with a <literal>#</literal> character. An example
|
||||||
|
configuration file is shown in <xref linkend="ex-nix-conf" />.</para>
|
||||||
|
|
||||||
|
<example id='ex-nix-conf'><title>Nix expression for GNU Hello</title>
|
||||||
|
|
||||||
|
<programlisting>
|
||||||
|
gc-keep-outputs = true # Nice for developers
|
||||||
|
gc-keep-derivations = true # Idem
|
||||||
|
env-keep-derivations = false
|
||||||
|
</programlisting>
|
||||||
|
</example>
|
||||||
|
|
||||||
|
<para>The following variables are currently available:
|
||||||
|
|
||||||
|
<variablelist>
|
||||||
|
|
||||||
|
<varlistentry id="conf-gc-keep-outputs"><term><literal>gc-keep-outputs</literal></term>
|
||||||
|
|
||||||
|
<listitem><para>If <literal>true</literal>, the garbage collector
|
||||||
|
will keep the outputs of non-garbage derivations. If
|
||||||
|
<literal>false</literal> (default), outputs will be deleted unless
|
||||||
|
they are GC roots themselves (or reachable from other roots).</para>
|
||||||
|
|
||||||
|
<para>In general, outputs must be registered as roots separately.
|
||||||
|
However, even if the output of a derivation is registered as a
|
||||||
|
root, the collector will still delete store paths that are used
|
||||||
|
only at build time (e.g., the C compiler, or source tarballs
|
||||||
|
downloaded from the network). To prevent it from doing so, set
|
||||||
|
this option to <literal>true</literal>.</para></listitem>
|
||||||
|
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry id="conf-gc-keep-derivations"><term><literal>gc-keep-derivations</literal></term>
|
||||||
|
|
||||||
|
<listitem><para>If <literal>true</literal> (default), the garbage
|
||||||
|
collector will keep the derivations from which non-garbage store
|
||||||
|
paths were built. If <literal>false</literal>, they will be
|
||||||
|
deleted unless explicitly registered as a root (or reachable from
|
||||||
|
other roots).</para>
|
||||||
|
|
||||||
|
<para>Keeping derivation around is useful for querying and
|
||||||
|
traceability (e.g., it allows you to ask with what dependencies or
|
||||||
|
options a store path was built), so by default this option is on.
|
||||||
|
Turn it off to safe a bit of disk space (or a lot if
|
||||||
|
<literal>gc-keep-outputs</literal> is also turned on).</para></listitem>
|
||||||
|
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry><term><literal>env-keep-derivations</literal></term>
|
||||||
|
|
||||||
|
<listitem><para>If <literal>false</literal> (default), derivations
|
||||||
|
are not stored in Nix user environments. That is, the derivation
|
||||||
|
any build-time-only dependencies may be garbage-collected.</para>
|
||||||
|
|
||||||
|
<para>If <literal>true</literal>, when you add a Nix derivation to
|
||||||
|
a user environment, the path of the derivation is stored in the
|
||||||
|
user environment. Thus, the derivation will not be
|
||||||
|
garbage-collected until the user environment generation is deleted
|
||||||
|
(<command>nix-env --delete-generations</command>). To prevent
|
||||||
|
build-time-only dependencies from being collected, you should also
|
||||||
|
turn on <literal>gc-keep-outputs</literal>.</para>
|
||||||
|
|
||||||
|
<para>The difference between this option and
|
||||||
|
<literal>gc-keep-derivations</literal> is that this one is
|
||||||
|
“sticky”: it applies to any user environment created while this
|
||||||
|
option was enabled, while <literal>gc-keep-derivations</literal>
|
||||||
|
only applies at the moment the garbage collector is
|
||||||
|
run.</para></listitem>
|
||||||
|
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
</variablelist>
|
||||||
|
|
||||||
|
</para>
|
||||||
|
|
||||||
|
</sect1>
|
||||||
|
|
@ -79,17 +79,47 @@
|
||||||
</glossentry>
|
</glossentry>
|
||||||
|
|
||||||
|
|
||||||
<glossentry><glossterm>closure</glossterm>
|
<glossentry 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>
|
||||||
|
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
|
||||||
|
<glossentry 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. For instance, if the store object at path
|
path; that is, it’s the closure of the path under the <link
|
||||||
<varname>P</varname> contains a reference to path
|
linkend="gloss-reference">references</link> relation. For instance,
|
||||||
<varname>Q</varname>, then <varname>Q</varname> is in the closure of
|
if the store object at path <varname>P</varname> contains a
|
||||||
<varname>P</varname>. For correct deployment it is necessary to
|
reference to path <varname>Q</varname>, then <varname>Q</varname> is
|
||||||
deploy whole closures, since otherwise at runtime files could be
|
in the closure of <varname>P</varname>. For correct deployment it
|
||||||
missing. The command <command>nix-store -qR</command> prints out
|
is necessary to deploy whole closures, since otherwise at runtime
|
||||||
closures of store paths.</para></glossdef>
|
files could be missing. The command <command>nix-store
|
||||||
|
-qR</command> prints out closures of store paths.</para></glossdef>
|
||||||
|
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
|
||||||
|
<glossentry id="gloss-output-path"><glossterm>output path</glossterm>
|
||||||
|
|
||||||
|
<glossdef><para>A store path produced by a derivation.</para></glossdef>
|
||||||
|
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
|
||||||
|
<glossentry id="gloss-deriver"><glossterm>deriver</glossterm>
|
||||||
|
|
||||||
|
<glossdef><para>The deriver of an <link
|
||||||
|
linkend="gloss-output-path">output path</link> is the store
|
||||||
|
derivation that built it.</para></glossdef>
|
||||||
|
|
||||||
</glossentry>
|
</glossentry>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -35,6 +35,7 @@
|
||||||
<title>Command Reference</title>
|
<title>Command Reference</title>
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="opt-common.xml" />
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="opt-common.xml" />
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="env-common.xml" />
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="env-common.xml" />
|
||||||
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="conf-file.xml" />
|
||||||
<sect1>
|
<sect1>
|
||||||
<title>nix-env</title>
|
<title>nix-env</title>
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-env.xml" />
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-env.xml" />
|
||||||
|
|
|
||||||
|
|
@ -10,14 +10,14 @@
|
||||||
<command>nix-push</command>
|
<command>nix-push</command>
|
||||||
<group choice='req'>
|
<group choice='req'>
|
||||||
<arg choice='req'>
|
<arg choice='req'>
|
||||||
<arg choice='plain'><replaceable>archives-put-url</replaceable></arg>
|
<arg choice='plain'><replaceable>archivesPutURL</replaceable></arg>
|
||||||
<arg choice='plain'><replaceable>archives-get-url</replaceable></arg>
|
<arg choice='plain'><replaceable>archivesGetURL</replaceable></arg>
|
||||||
<arg choice='plain'><replaceable>manifest-put-url</replaceable></arg>
|
<arg choice='plain'><replaceable>manifestPutURL</replaceable></arg>
|
||||||
</arg>
|
</arg>
|
||||||
<arg choice='req'>
|
<arg choice='req'>
|
||||||
<arg choice='plain'><option>--copy</option></arg>
|
<arg choice='plain'><option>--copy</option></arg>
|
||||||
<arg choice='plain'><replaceable>archives-dir</replaceable></arg>
|
<arg choice='plain'><replaceable>archivesDir</replaceable></arg>
|
||||||
<arg choice='plain'><replaceable>manifest-file</replaceable></arg>
|
<arg choice='plain'><replaceable>manifestFile</replaceable></arg>
|
||||||
</arg>
|
</arg>
|
||||||
</group>
|
</group>
|
||||||
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
|
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
|
||||||
|
|
@ -59,20 +59,20 @@ machines using the <command>nix-pull</command> command.</para>
|
||||||
archives.</para></listitem>
|
archives.</para></listitem>
|
||||||
|
|
||||||
<listitem><para>Each store path is uploaded to the remote directory
|
<listitem><para>Each store path is uploaded to the remote directory
|
||||||
specified by <replaceable>archives-put-url</replaceable>. HTTP PUT
|
specified by <replaceable>archivesPutURL</replaceable>. HTTP PUT
|
||||||
requests are used to do this. However, before a file
|
requests are used to do this. However, before a file
|
||||||
<varname>x</varname> is uploaded to
|
<varname>x</varname> is uploaded to
|
||||||
<literal><replaceable>archives-put-url</replaceable>/<varname>x</varname></literal>,
|
<literal><replaceable>archivesPutURL</replaceable>/<varname>x</varname></literal>,
|
||||||
<command>nix-push</command> first determines whether this upload is
|
<command>nix-push</command> first determines whether this upload is
|
||||||
unnecessary by issuing a HTTP HEAD request on
|
unnecessary by issuing a HTTP HEAD request on
|
||||||
<literal><replaceable>archives-get-url</replaceable>/<varname>x</varname></literal>.
|
<literal><replaceable>archivesGetURL</replaceable>/<varname>x</varname></literal>.
|
||||||
This allows a cache to be shared between many partially overlapping
|
This allows a cache to be shared between many partially overlapping
|
||||||
<command>nix-push</command> invocations. (We use two URLs because
|
<command>nix-push</command> invocations. (We use two URLs because
|
||||||
the upload URL typically refers to a CGI script, while the download
|
the upload URL typically refers to a CGI script, while the download
|
||||||
URL just refers to a file system directory on the server.)</para></listitem>
|
URL just refers to a file system directory on the server.)</para></listitem>
|
||||||
|
|
||||||
<listitem><para>The manifest is uploaded using an HTTP PUT request
|
<listitem><para>The manifest is uploaded using an HTTP PUT request
|
||||||
to <replaceable>manifest-put-url</replaceable>. The corresponding
|
to <replaceable>manifestPutURL</replaceable>. The corresponding
|
||||||
URL to download the manifest can then be used by
|
URL to download the manifest can then be used by
|
||||||
<command>nix-pull</command>.</para></listitem>
|
<command>nix-pull</command>.</para></listitem>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -168,7 +168,8 @@ produced by <link
|
||||||
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>:
|
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-store -r $(nix-instantiate ./foo.nix)</screen>
|
$ nix-store -r $(nix-instantiate ./test.nix)
|
||||||
|
/nix/store/31axcgrlbfsxzmfff1gyj1bf62hvkby2-aterm-2.3.1</screen>
|
||||||
|
|
||||||
This is essentially what <link
|
This is essentially what <link
|
||||||
linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
|
linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
|
||||||
|
|
@ -213,7 +214,9 @@ the Nix store not reachable via file system references from a set of
|
||||||
<varlistentry><term><option>--print-roots</option></term>
|
<varlistentry><term><option>--print-roots</option></term>
|
||||||
|
|
||||||
<listitem><para>This operation prints on standard output the set
|
<listitem><para>This operation prints on standard output the set
|
||||||
of roots used by the garbage collector.</para></listitem>
|
of roots used by the garbage collector. What constitutes a root
|
||||||
|
is described in <xref linkend="ssec-gc-roots"
|
||||||
|
/>.</para></listitem>
|
||||||
|
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
|
@ -247,35 +250,11 @@ the Nix store not reachable via file system references from a set of
|
||||||
|
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
</refsection>
|
<para>The behaviour of the collector is influenced by the <link
|
||||||
|
linkend="conf-gc-keep-outputs"><literal>gc-keep-outputs</literal></link>
|
||||||
|
and <link
|
||||||
<refsection><title>Roots</title>
|
linkend="conf-gc-keep-derivations"><literal>gc-keep-derivations</literal></link>
|
||||||
|
variables in the Nix configuration file.</para>
|
||||||
<para>The roots of the garbage collector are all store paths to which
|
|
||||||
there are symlinks in the directory
|
|
||||||
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>.
|
|
||||||
For instance, the following command makes the path
|
|
||||||
<filename>/nix/store/d718ef...-foo</filename> a root of the collector:
|
|
||||||
|
|
||||||
<screen>
|
|
||||||
$ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar</screen>
|
|
||||||
|
|
||||||
That is, after this command, the garbage collector will not remove
|
|
||||||
<filename>/nix/store/d718ef...-foo</filename> or any of its
|
|
||||||
dependencies.</para>
|
|
||||||
|
|
||||||
<para>Subdirectories of
|
|
||||||
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>
|
|
||||||
are also searched for symlinks. Symlinks to non-store paths are
|
|
||||||
followed and searched for roots, but TODO.</para>
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
<refsection><title>Configuration file</title>
|
|
||||||
|
|
||||||
<para>TODO</para>
|
|
||||||
|
|
||||||
</refsection>
|
</refsection>
|
||||||
|
|
||||||
|
|
@ -309,18 +288,24 @@ $ nix-store --gc</screen>
|
||||||
<arg choice='plain'><option>-q</option></arg>
|
<arg choice='plain'><option>-q</option></arg>
|
||||||
</group>
|
</group>
|
||||||
<group choice='req'>
|
<group choice='req'>
|
||||||
<arg choice='plain'><option>--list</option></arg>
|
<arg choice='plain'><option>--outputs</option></arg>
|
||||||
<arg choice='plain'><option>-l</option></arg>
|
|
||||||
<arg choice='plain'><option>--requisites</option></arg>
|
<arg choice='plain'><option>--requisites</option></arg>
|
||||||
<arg choice='plain'><option>-R</option></arg>
|
<arg choice='plain'><option>-R</option></arg>
|
||||||
<arg choice='plain'><option>--predecessors</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>--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>
|
</group>
|
||||||
<arg><option>--normalise</option></arg>
|
<arg><option>--use-output</option></arg>
|
||||||
<arg><option>-n</option></arg>
|
<arg><option>-u</option></arg>
|
||||||
<arg><option>--force-realise</option></arg>
|
<arg><option>--force-realise</option></arg>
|
||||||
<arg><option>-f</option></arg>
|
<arg><option>-f</option></arg>
|
||||||
<arg choice='plain' rep='repeat'><replaceable>args</replaceable></arg>
|
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
|
|
||||||
</refsection>
|
</refsection>
|
||||||
|
|
@ -329,9 +314,14 @@ $ nix-store --gc</screen>
|
||||||
<refsection><title>Description</title>
|
<refsection><title>Description</title>
|
||||||
|
|
||||||
<para>The operation <option>--query</option> displays various bits of
|
<para>The operation <option>--query</option> displays various bits of
|
||||||
information about store paths. The queries are described below. At
|
information about the store paths . The queries are described below. At
|
||||||
most one query can be specified. The default query is
|
most one query can be specified. The default query is
|
||||||
<option>--list</option>.</para>
|
<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>
|
||||||
|
|
||||||
|
|
@ -365,47 +355,21 @@ most one query can be specified. The default query is
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
|
|
||||||
<varlistentry><term><option>--list</option> / <option>-l</option></term>
|
<varlistentry><term><option>--outputs</option></term>
|
||||||
|
|
||||||
<listitem><para>Prints out the <emphasis>output paths</emphasis>
|
<listitem><para>Prints out the <link
|
||||||
of the store expressions indicated by the identifiers
|
linkend="gloss-output-path">output paths</link> of the store
|
||||||
<replaceable>args</replaceable>. In the case of a derivation
|
derivations <replaceable>paths</replaceable>. These are the paths
|
||||||
expression, these are the paths that will be produced when the
|
that will be produced when the derivation is
|
||||||
derivation is realised. In the case of a closure expression,
|
built.</para></listitem>
|
||||||
these are the paths that were produced the derivation expression
|
|
||||||
of which the closure expression is a successor.</para></listitem>
|
|
||||||
|
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term><option>--requisites</option> / <option>-R</option></term>
|
<varlistentry><term><option>--requisites</option> / <option>-R</option></term>
|
||||||
|
|
||||||
<listitem><para>Prints out the requisite paths of the store
|
<listitem><para>Prints out the <link
|
||||||
expressions indicated by the identifiers
|
linkend="gloss-closure">closure</link> of the store path
|
||||||
<replaceable>args</replaceable>. The requisite paths of a Nix
|
<replaceable>paths</replaceable>.</para>
|
||||||
expression are the paths that need to be present in the system to
|
|
||||||
be able to realise the expression. That is, they form the
|
|
||||||
<emphasis>closure</emphasis> of the expression in the file system
|
|
||||||
(i.e., no path in the set of requisite paths points to anything
|
|
||||||
outside the set of requisite paths).</para>
|
|
||||||
|
|
||||||
<para>The notion of requisite paths is very useful when one wants
|
|
||||||
to distribute store expressions. Since they form a closure, they
|
|
||||||
are the only paths one needs to distribute to another system to be
|
|
||||||
able to realise the expression on the other system.</para>
|
|
||||||
|
|
||||||
<para>This query is generally used to implement various kinds of
|
|
||||||
deployment. A <emphasis>source deployment</emphasis> is obtained
|
|
||||||
by distributing the requisite paths of a derivation expression. A
|
|
||||||
<emphasis>binary deployment</emphasis> is obtained by distributing
|
|
||||||
the requisite paths of a closure expression. A <emphasis>cache
|
|
||||||
deployment</emphasis> is obtained by distributing the requisite
|
|
||||||
paths of a derivation expression and specifying the option
|
|
||||||
<option>--include-successors</option>. This will include not just
|
|
||||||
the paths of a source and binary deployment, but also all
|
|
||||||
expressions and paths of subterms of the source. This is useful
|
|
||||||
if one wants to realise on the target system a Nix expression that
|
|
||||||
is similar but not quite the same as the one being distributed,
|
|
||||||
since any common subterms will be reused.</para>
|
|
||||||
|
|
||||||
<para>This query has one option:</para>
|
<para>This query has one option:</para>
|
||||||
|
|
||||||
|
|
@ -420,17 +384,104 @@ most one query can be specified. The default query is
|
||||||
|
|
||||||
</variablelist>
|
</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>
|
</listitem>
|
||||||
|
|
||||||
</varlistentry>
|
</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>
|
<varlistentry><term><option>--graph</option></term>
|
||||||
|
|
||||||
<listitem><para>Prints a graph of the closure of the store
|
<listitem><para>Prints the references graph of the store paths
|
||||||
expressions identified by <replaceable>args</replaceable> in the
|
<replaceable>paths</replaceable> in the format of the
|
||||||
format of the <command>dot</command> tool of AT&T's GraphViz
|
<command>dot</command> tool of AT&T's <ulink
|
||||||
package.</para></listitem>
|
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>
|
</varlistentry>
|
||||||
|
|
||||||
|
|
@ -439,6 +490,81 @@ most one query can be specified. The default query is
|
||||||
</refsection>
|
</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>
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -35,33 +35,33 @@
|
||||||
<variablelist>
|
<variablelist>
|
||||||
|
|
||||||
<varlistentry><term>0</term>
|
<varlistentry><term>0</term>
|
||||||
<listitem><para><quote>Errors only</quote>: only print messages
|
<listitem><para>“Errors only”: only print messages
|
||||||
explaining why the Nix invocation failed.</para></listitem>
|
explaining why the Nix invocation failed.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term>1</term>
|
<varlistentry><term>1</term>
|
||||||
<listitem><para><quote>Informational</quote>: print
|
<listitem><para>“Informational”: print
|
||||||
<emphasis>useful</emphasis> messages about what Nix is doing.
|
<emphasis>useful</emphasis> messages about what Nix is doing.
|
||||||
This is the default.</para></listitem>
|
This is the default.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term>2</term>
|
<varlistentry><term>2</term>
|
||||||
<listitem><para><quote>Talkative</quote>: print more informational
|
<listitem><para>“Talkative”: print more informational
|
||||||
messages.</para></listitem>
|
messages.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term>3</term>
|
<varlistentry><term>3</term>
|
||||||
<listitem><para><quote>Chatty</quote>: print even more
|
<listitem><para>“Chatty”: print even more
|
||||||
informational messages.</para></listitem>
|
informational messages.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term>4</term>
|
<varlistentry><term>4</term>
|
||||||
<listitem><para><quote>Debug</quote>: print debug
|
<listitem><para>“Debug”: print debug
|
||||||
information.</para></listitem>
|
information.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry><term>5</term>
|
<varlistentry><term>5</term>
|
||||||
<listitem><para><quote>Vomit</quote>: print vast amounts of debug
|
<listitem><para>“Vomit”: print vast amounts of debug
|
||||||
information.</para></listitem>
|
information.</para></listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
|
@ -120,19 +120,21 @@
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
|
|
||||||
<para>Whenever Nix attempts to realise a derivation for which a
|
<para>Whenever Nix attempts to build a derivation for which
|
||||||
closure is already known, but this closure cannot be realised, fall
|
substitutes are known for each output path, but realising the output
|
||||||
back on normalising the derivation.</para>
|
paths through the substitutes fails, fall back on building the
|
||||||
|
derivation.</para>
|
||||||
|
|
||||||
<para>The most common scenario in which this is useful is when we
|
<para>The most common scenario in which this is useful is when we
|
||||||
have registered substitutes in order to perform binary distribution
|
have registered substitutes in order to perform binary distribution
|
||||||
from, say, a network repository. If the repository is down, the
|
from, say, a network repository. If the repository is down, the
|
||||||
realisation of the derivation will fail. When this option is
|
realisation of the derivation will fail. When this option is
|
||||||
specified, Nix will build the derivation instead. Thus, binary
|
specified, Nix will build the derivation instead. Thus,
|
||||||
installation falls back on a source installation. This option is
|
installation from binaries falls back on nstallation from source.
|
||||||
not the default since it is generally not desirable for a transient
|
This option is not the default since it is generally not desirable
|
||||||
failure in obtaining the substitutes to lead to a full build from
|
for a transient failure in obtaining the substitutes to lead to a
|
||||||
source (with the related consumption of resources).</para>
|
full build from source (with the related consumption of
|
||||||
|
resources).</para>
|
||||||
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -369,30 +369,39 @@ $ nix-env --delete-generations 10 11 14</screen>
|
||||||
garbage collector as follows:
|
garbage collector as follows:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-collect-garbage</screen>
|
$ nix-store --gc</screen>
|
||||||
|
|
||||||
You can alo first view what files would be deleted:
|
If you are feeling uncertain, you can also first view what files would
|
||||||
|
be deleted:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-collect-garbage --print-dead</screen>
|
$ nix-store --gc --print-dead</screen>
|
||||||
|
|
||||||
Likewise, the option <option>--print-live</option> will show the paths
|
Likewise, the option <option>--print-live</option> will show the paths
|
||||||
that <emphasis>won’t</emphasis> be deleted.</para>
|
that <emphasis>won’t</emphasis> be deleted.</para>
|
||||||
|
|
||||||
|
|
||||||
<sect2 id="ssec-gc-roots"><title>Garbage collector roots</title>
|
<sect2 id="ssec-gc-roots"><title>Garbage collector roots</title>
|
||||||
|
|
||||||
<para>TODO</para>
|
<para>The roots of the garbage collector are all store paths to which
|
||||||
|
there are symlinks in the directory
|
||||||
|
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>.
|
||||||
|
For instance, the following command makes the path
|
||||||
|
<filename>/nix/store/d718ef...-foo</filename> a root of the collector:
|
||||||
|
|
||||||
<para>The garbage collector uses as roots all store expressions
|
<screen>
|
||||||
mentioned in all files with extension <filename>.gcroot</filename> in
|
$ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar</screen>
|
||||||
the directory
|
|
||||||
<filename><replaceable>prefix</replaceable>/var/nix/gcroots/</filename>,
|
That is, after this command, the garbage collector will not remove
|
||||||
or in any file or directory symlinked to from that directory. E.g.,
|
<filename>/nix/store/d718ef...-foo</filename> or any of its
|
||||||
by default,
|
dependencies.</para>
|
||||||
<filename><replaceable>prefix</replaceable>/var/nix/gcroots/</filename>
|
|
||||||
contains a symlink to
|
<para>Subdirectories of
|
||||||
<filename><replaceable>prefix</replaceable>/var/nix/profiles/</filename>,
|
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>
|
||||||
so all generations of all profiles are also roots of the collector.</para>
|
are also searched for symlinks. Symlinks to non-store paths are
|
||||||
|
followed and searched for roots, but symlinks to non-store paths
|
||||||
|
<emphasis>inside</emphasis> the paths reached in that way are not
|
||||||
|
followed to prevent infinite recursion.</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -88,8 +88,8 @@ $ nix-channel --update
|
||||||
$ nix-env -u '*'</screen>
|
$ nix-env -u '*'</screen>
|
||||||
|
|
||||||
The latter command will upgrade each installed component for which
|
The latter command will upgrade each installed component for which
|
||||||
there is a <quote>newer</quote> version (as determined by comparing
|
there is a “newer” version (as determined by comparing the version
|
||||||
the version numbers).</para></listitem>
|
numbers).</para></listitem>
|
||||||
|
|
||||||
<listitem><para>If you're unhappy with the result of a
|
<listitem><para>If you're unhappy with the result of a
|
||||||
<command>nix-env</command> action (e.g., an upgraded component turned
|
<command>nix-env</command> action (e.g., an upgraded component turned
|
||||||
|
|
@ -106,12 +106,12 @@ actually delete them:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env --delete-generations old
|
$ nix-env --delete-generations old
|
||||||
$ nix-collect-garbage</screen>
|
$ nix-store --gc</screen>
|
||||||
|
|
||||||
The first command deletes old <quote>generations</quote> of your
|
The first command deletes old “generations” of your profile (making
|
||||||
profile (making rollbacks impossible, but also making the components
|
rollbacks impossible, but also making the components in those old
|
||||||
in those old generations available for garbage collection), while the
|
generations available for garbage collection), while the second
|
||||||
second command actually deletes them.</para></listitem>
|
command actually deletes them.</para></listitem>
|
||||||
|
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,31 +1,71 @@
|
||||||
<appendix>
|
<appendix><title>Troubleshooting</title>
|
||||||
<title>Troubleshooting</title>
|
|
||||||
|
|
||||||
<para>This section provides solutions for some common problems.</para>
|
<para>This section provides solutions for some common problems.</para>
|
||||||
|
|
||||||
<sect1><title>Berkeley DB: <quote>Cannot allocate memory</quote></title>
|
|
||||||
|
|
||||||
<para>Symptom: Nix operations (in particular the
|
<sect1><title>Berkeley DB: <quote>Cannot allocate memory</quote></title>
|
||||||
<command>nix-store</command> operations <option>--gc</option>,
|
|
||||||
<option>--verify</option>, and <option>--clear-substitutes</option>
|
<para>Symptom: Nix operations (in particular the
|
||||||
— the latter being called by <command>nix-channel
|
<command>nix-store</command> operations <option>--gc</option>,
|
||||||
--update</command>) failing:
|
<option>--verify</option>, and <option>--clear-substitutes</option> —
|
||||||
|
the latter being called by <command>nix-channel --update</command>)
|
||||||
|
failing:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-store --verify
|
$ nix-store --verify
|
||||||
error: Db::del: Cannot allocate memory</screen>
|
error: Db::del: Cannot allocate memory</screen>
|
||||||
|
|
||||||
Possible solution: make sure that no Nix processes are running,
|
</para>
|
||||||
then do:
|
|
||||||
|
<para>Possible solution: make sure that no Nix processes are running,
|
||||||
|
then do:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ cd /nix/var/nix/db
|
$ cd /nix/var/nix/db
|
||||||
$ rm __db.00*</screen>
|
$ rm __db.00*</screen>
|
||||||
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
</sect1>
|
<sect1><title>Collisions in <command>nix-env</command></title>
|
||||||
|
|
||||||
|
<para>Symptom: when installing or upgrading, you get an error message such as
|
||||||
|
|
||||||
|
<screen>
|
||||||
|
$ nix-env -i docbook-xml
|
||||||
|
...
|
||||||
|
adding /nix/store/s5hyxgm62gk2...-docbook-xml-4.2
|
||||||
|
collission between `/nix/store/s5hyxgm62gk2...-docbook-xml-4.2/xml/dtd/docbook/calstblx.dtd'
|
||||||
|
and `/nix/store/06h377hr4b33...-docbook-xml-4.3/xml/dtd/docbook/calstblx.dtd'
|
||||||
|
at /nix/store/...-builder.pl line 62.</screen>
|
||||||
|
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>The cause is that two installed packages in the user environment
|
||||||
|
have overlapping filenames (e.g.,
|
||||||
|
<filename>xml/dtd/docbook/calstblx.dtd</filename>. This usually
|
||||||
|
happens when you accidentally try to install two versions of the same
|
||||||
|
package. For instance, in the example above, the Nix Packages
|
||||||
|
collection contains two versions of <literal>docbook-xml</literal>, so
|
||||||
|
<command>nix-env -i</command> will try to install both. The default
|
||||||
|
user environment builder has no way to way to resolve such conflicts,
|
||||||
|
so it just gives up.</para>
|
||||||
|
|
||||||
|
<para>Solution: remove one of the offending packages from the user
|
||||||
|
environment (if already installed) using <command>nix-env
|
||||||
|
-u</command>, or specify exactly which version should be installed
|
||||||
|
(e.g., <literal>nix-env -i docbook-xml-4.2</literal>).</para>
|
||||||
|
|
||||||
|
<para>Alternatively, you can modify the user environment builder
|
||||||
|
script (in
|
||||||
|
<filename><replaceable>prefix</replaceable>/share/nix/corepkgs/buildenv/builder.pl</filename>)
|
||||||
|
to implement some conflict resolution policy. E.g., the script could
|
||||||
|
be modified to rename conflicting file names, or to pick one over the
|
||||||
|
other.</para>
|
||||||
|
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
</appendix>
|
</appendix>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue