175 lines
		
	
	
	
		
			7.6 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			175 lines
		
	
	
	
		
			7.6 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
<section xmlns="http://docbook.org/ns/docbook"
 | 
						||
      xmlns:xlink="http://www.w3.org/1999/xlink"
 | 
						||
      xmlns:xi="http://www.w3.org/2001/XInclude"
 | 
						||
      version="5.0"
 | 
						||
      xml:id="ssec-relnotes-0.12">
 | 
						||
 | 
						||
<title>Release 0.12 (2008-11-20)</title>
 | 
						||
 | 
						||
<itemizedlist>
 | 
						||
 | 
						||
  <listitem>
 | 
						||
    <para>Nix no longer uses Berkeley DB to store Nix store metadata.
 | 
						||
    The principal advantages of the new storage scheme are: it works
 | 
						||
    properly over decent implementations of NFS (allowing Nix stores
 | 
						||
    to be shared between multiple machines); no recovery is needed
 | 
						||
    when a Nix process crashes; no write access is needed for
 | 
						||
    read-only operations; no more running out of Berkeley DB locks on
 | 
						||
    certain operations.</para>
 | 
						||
 | 
						||
    <para>You still need to compile Nix with Berkeley DB support if
 | 
						||
    you want Nix to automatically convert your old Nix store to the
 | 
						||
    new schema.  If you don’t need this, you can build Nix with the
 | 
						||
    <filename>configure</filename> option
 | 
						||
    <option>--disable-old-db-compat</option>.</para>
 | 
						||
 | 
						||
    <para>After the automatic conversion to the new schema, you can
 | 
						||
    delete the old Berkeley DB files:
 | 
						||
 | 
						||
    <screen>
 | 
						||
$ cd /nix/var/nix/db
 | 
						||
$ rm __db* log.* derivers references referrers reserved validpaths DB_CONFIG</screen>
 | 
						||
 | 
						||
    The new metadata is stored in the directories
 | 
						||
    <filename>/nix/var/nix/db/info</filename> and
 | 
						||
    <filename>/nix/var/nix/db/referrer</filename>.  Though the
 | 
						||
    metadata is stored in human-readable plain-text files, they are
 | 
						||
    not intended to be human-editable, as Nix is rather strict about
 | 
						||
    the format.</para>
 | 
						||
 | 
						||
    <para>The new storage schema may or may not require less disk
 | 
						||
    space than the Berkeley DB environment, mostly depending on the
 | 
						||
    cluster size of your file system.  With 1 KiB clusters (which
 | 
						||
    seems to be the <literal>ext3</literal> default nowadays) it
 | 
						||
    usually takes up much less space.</para>
 | 
						||
  </listitem>
 | 
						||
 | 
						||
  <listitem><para>There is a new substituter that copies paths
 | 
						||
  directly from other (remote) Nix stores mounted somewhere in the
 | 
						||
  filesystem.  For instance, you can speed up an installation by
 | 
						||
  mounting some remote Nix store that already has the packages in
 | 
						||
  question via NFS or <literal>sshfs</literal>.  The environment
 | 
						||
  variable <envar>NIX_OTHER_STORES</envar> specifies the locations of
 | 
						||
  the remote Nix directories,
 | 
						||
  e.g. <literal>/mnt/remote-fs/nix</literal>.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>New <command>nix-store</command> operations
 | 
						||
  <option>--dump-db</option> and <option>--load-db</option> to dump
 | 
						||
  and reload the Nix database.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>The garbage collector has a number of new options to
 | 
						||
  allow only some of the garbage to be deleted.  The option
 | 
						||
  <option>--max-freed <replaceable>N</replaceable></option> tells the
 | 
						||
  collector to stop after at least <replaceable>N</replaceable> bytes
 | 
						||
  have been deleted.  The option <option>--max-links
 | 
						||
  <replaceable>N</replaceable></option> tells it to stop after the
 | 
						||
  link count on <filename>/nix/store</filename> has dropped below
 | 
						||
  <replaceable>N</replaceable>.  This is useful for very large Nix
 | 
						||
  stores on filesystems with a 32000 subdirectories limit (like
 | 
						||
  <literal>ext3</literal>).  The option <option>--use-atime</option>
 | 
						||
  causes store paths to be deleted in order of ascending last access
 | 
						||
  time.  This allows non-recently used stuff to be deleted.  The
 | 
						||
  option <option>--max-atime <replaceable>time</replaceable></option>
 | 
						||
  specifies an upper limit to the last accessed time of paths that may
 | 
						||
  be deleted.  For instance,
 | 
						||
 | 
						||
    <screen>
 | 
						||
    $ nix-store --gc -v --max-atime $(date +%s -d "2 months ago")</screen>
 | 
						||
 | 
						||
  deletes everything that hasn’t been accessed in two months.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para><command>nix-env</command> now uses optimistic
 | 
						||
  profile locking when performing an operation like installing or
 | 
						||
  upgrading, instead of setting an exclusive lock on the profile.
 | 
						||
  This allows multiple <command>nix-env -i / -u / -e</command>
 | 
						||
  operations on the same profile in parallel.  If a
 | 
						||
  <command>nix-env</command> operation sees at the end that the profile
 | 
						||
  was changed in the meantime by another process, it will just
 | 
						||
  restart.  This is generally cheap because the build results are
 | 
						||
  still in the Nix store.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>The option <option>--dry-run</option> is now
 | 
						||
  supported by <command>nix-store -r</command> and
 | 
						||
  <command>nix-build</command>.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>The information previously shown by
 | 
						||
  <option>--dry-run</option> (i.e., which derivations will be built
 | 
						||
  and which paths will be substituted) is now always shown by
 | 
						||
  <command>nix-env</command>, <command>nix-store -r</command> and
 | 
						||
  <command>nix-build</command>.  The total download size of
 | 
						||
  substitutable paths is now also shown.  For instance, a build will
 | 
						||
  show something like
 | 
						||
 | 
						||
    <screen>
 | 
						||
the following derivations will be built:
 | 
						||
  /nix/store/129sbxnk5n466zg6r1qmq1xjv9zymyy7-activate-configuration.sh.drv
 | 
						||
  /nix/store/7mzy971rdm8l566ch8hgxaf89x7lr7ik-upstart-jobs.drv
 | 
						||
  ...
 | 
						||
the following paths will be downloaded/copied (30.02 MiB):
 | 
						||
  /nix/store/4m8pvgy2dcjgppf5b4cj5l6wyshjhalj-samba-3.2.4
 | 
						||
  /nix/store/7h1kwcj29ip8vk26rhmx6bfjraxp0g4l-libunwind-0.98.6
 | 
						||
  ...</screen>
 | 
						||
 | 
						||
  </para></listitem>
 | 
						||
 | 
						||
  <listitem><para>Language features:
 | 
						||
 | 
						||
    <itemizedlist>
 | 
						||
 | 
						||
      <listitem><para>@-patterns as in Haskell.  For instance, in a
 | 
						||
      function definition
 | 
						||
 | 
						||
      <programlisting>f = args @ {x, y, z}: <replaceable>...</replaceable>;</programlisting>
 | 
						||
 | 
						||
      <varname>args</varname> refers to the argument as a whole, which
 | 
						||
      is further pattern-matched against the attribute set pattern
 | 
						||
      <literal>{x, y, z}</literal>.</para></listitem>
 | 
						||
 | 
						||
      <listitem><para>“<literal>...</literal>” (ellipsis) patterns.
 | 
						||
      An attribute set pattern can now say <literal>...</literal>  at
 | 
						||
      the end of the attribute name list to specify that the function
 | 
						||
      takes <emphasis>at least</emphasis> the listed attributes, while
 | 
						||
      ignoring additional attributes.  For instance,
 | 
						||
 | 
						||
      <programlisting>{stdenv, fetchurl, fuse, ...}: <replaceable>...</replaceable></programlisting>
 | 
						||
 | 
						||
      defines a function that accepts any attribute set that includes
 | 
						||
      at least the three listed attributes.</para></listitem>
 | 
						||
 | 
						||
      <listitem><para>New primops:
 | 
						||
      <varname>builtins.parseDrvName</varname> (split a package name
 | 
						||
      string like <literal>"nix-0.12pre12876"</literal> into its name
 | 
						||
      and version components, e.g. <literal>"nix"</literal> and
 | 
						||
      <literal>"0.12pre12876"</literal>),
 | 
						||
      <varname>builtins.compareVersions</varname> (compare two version
 | 
						||
      strings using the same algorithm that <command>nix-env</command>
 | 
						||
      uses), <varname>builtins.length</varname> (efficiently compute
 | 
						||
      the length of a list), <varname>builtins.mul</varname> (integer
 | 
						||
      multiplication), <varname>builtins.div</varname> (integer
 | 
						||
      division).
 | 
						||
      <!-- <varname>builtins.genericClosure</varname> -->
 | 
						||
      </para></listitem>
 | 
						||
 | 
						||
    </itemizedlist>
 | 
						||
 | 
						||
  </para></listitem>
 | 
						||
 | 
						||
  <listitem><para><command>nix-prefetch-url</command> now supports
 | 
						||
  <literal>mirror://</literal> URLs, provided that the environment
 | 
						||
  variable <envar>NIXPKGS_ALL</envar> points at a Nixpkgs
 | 
						||
  tree.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>Removed the commands
 | 
						||
  <command>nix-pack-closure</command> and
 | 
						||
  <command>nix-unpack-closure</command>.   You can do almost the same
 | 
						||
  thing but much more efficiently by doing <literal>nix-store --export
 | 
						||
  $(nix-store -qR <replaceable>paths</replaceable>) > closure</literal> and
 | 
						||
  <literal>nix-store --import <
 | 
						||
  closure</literal>.</para></listitem>
 | 
						||
 | 
						||
  <listitem><para>Lots of bug fixes, including a big performance bug in
 | 
						||
  the handling of <literal>with</literal>-expressions.</para></listitem>
 | 
						||
 | 
						||
</itemizedlist>
 | 
						||
 | 
						||
</section>
 |