5396304c73
more common than the latter (which exists only on Linux and FreeBSD). We don't really care about dropping the saved IDs since there apparently is no way to quiry them in any case, so it can't influence the build (unlike the effective IDs which are checked by Perl for instance).
115 lines
4.6 KiB
XML
115 lines
4.6 KiB
XML
<appendix><title>Bugs / To-Do</title>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
The man-pages generated from the DocBook documentation are ugly.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Generations properly form a tree. E.g., if after switching to
|
|
generation 39, we perform an installation action, a generation
|
|
43 is created which is a descendant of 39, not 42. So a
|
|
rollback from 43 ought to go back to 39. This is not
|
|
currently implemented; generations form a linear sequence.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Unify the concepts of successors and substitutes into a
|
|
general notion of <emphasis>equivalent expressions</emphasis>.
|
|
Expressions are equivalent if they have the same target paths
|
|
with the same identifiers. However, even though they are
|
|
functionally equivalent, they may differ stronly with respect
|
|
to their <emphasis>performance characteristics</emphasis>.
|
|
For example, realising a closure expression is more efficient
|
|
that realising the derivation expression from which it was
|
|
produced. On the other hand, distributing sources may be more
|
|
efficient (storage- or bandwidth-wise) than distributing
|
|
binaries. So we need to be able to attach weigths or
|
|
priorities or performance annotations to expressions; Nix can
|
|
then choose the most efficient expression dependent on the
|
|
context.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Build management.</emphasis> In principle it is already
|
|
possible to do build management using Nix (by writing builders that
|
|
perform appropriate build steps), but the Nix expression language is
|
|
not yet powerful enough to make this pleasant (?). The language should
|
|
be extended with features from the <ulink
|
|
url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>.
|
|
Another interesting idea is to write a <command>make</command>
|
|
implementation that uses Nix as a back-end to support <ulink
|
|
url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
|
|
build files.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The current garbage collector is a hack. It should be
|
|
integrated into <command>nix-store</command>. It should
|
|
delete derivations in an order determined by topologically
|
|
sorting derivations under the points-to relation. This
|
|
ensures that no store paths ever exist that point to
|
|
non-existant store paths.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
There are race conditions between the garbage collector and
|
|
other Nix tools. For instance, when we run
|
|
<command>nix-env</command> to build and install a derivation
|
|
and run the garbage collector at the same time, the garbage
|
|
collector may kick in exactly between the build and
|
|
installation steps, i.e., before the newly built derivation
|
|
has become reachable from a root of the garbage collector.
|
|
</para>
|
|
|
|
<para>
|
|
One solution would be for these programs to properly register
|
|
temporary roots for the collector. Another would be to use
|
|
stop-the-world garbage collection: if any tool is running, the
|
|
garbage collector blocks, and vice versa. These solutions do
|
|
not solve the situation where multiple tools are involved,
|
|
e.g.,
|
|
|
|
<screen>
|
|
$ nix-store -r $(nix-instantiate foo.nix)</screen>
|
|
|
|
since even if <command>nix-instantiate</command> where to
|
|
register a temporary root, it would be released by the time
|
|
<command>nix-store</command> is started. A solution would be
|
|
to write the intermediate value to a file that is used as a
|
|
root to the collector, e.g.,
|
|
|
|
<screen>
|
|
$ nix-instantiate foo.nix > /nix/var/nix/roots/bla
|
|
$ nix-store -r $(cat /nix/var/nix/roots/bla)</screen>
|
|
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem><para>For security, <command>nix-push</command> manifests
|
|
should be digitally signed, and <command>nix-pull</command> should
|
|
verify the signatures. The actual NAR archives in the cache do not
|
|
need to be signed, since the manifest contains cryptographic hashes of
|
|
these files (and <filename>fetchurl.nix</filename> checks
|
|
them).</para></listitem>
|
|
|
|
<listitem><para>We should switch away from MD5, since it has been
|
|
cracked. We don't currently depend very much on the
|
|
collision-resistance of MD5, but we will once we start sharing build
|
|
results between users.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</appendix>
|