246 lines
		
	
	
		
			No EOL
		
	
	
		
			8.6 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			246 lines
		
	
	
		
			No EOL
		
	
	
		
			8.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="ch-relnotes-0.8">
 | 
						|
 | 
						|
<title>Release 0.8 (April 11, 2005)</title>
 | 
						|
 | 
						|
<para>NOTE: the hashing scheme in Nix 0.8 changed (as detailed below).
 | 
						|
As a result, <command>nix-pull</command> manifests and channels built
 | 
						|
for Nix 0.7 and below will now work anymore.  However, the Nix
 | 
						|
expression language has not changed, so you can still build from
 | 
						|
source.  Also, existing user environments continue to work.  Nix 0.8
 | 
						|
will automatically upgrade the database schema of previous
 | 
						|
installations when it is first run.</para>
 | 
						|
 | 
						|
<para>If you get the error message
 | 
						|
 | 
						|
<screen>
 | 
						|
you have an old-style manifest `/nix/var/nix/manifests/[...]'; please
 | 
						|
delete it</screen>
 | 
						|
 | 
						|
you should delete previously downloaded manifests:
 | 
						|
 | 
						|
<screen>
 | 
						|
$ rm /nix/var/nix/manifests/*</screen>
 | 
						|
 | 
						|
If <command>nix-channel</command> gives the error message
 | 
						|
 | 
						|
<screen>
 | 
						|
manifest `http://catamaran.labs.cs.uu.nl/dist/nix/channels/[channel]/MANIFEST'
 | 
						|
is too old (i.e., for Nix <= 0.7)</screen>
 | 
						|
 | 
						|
then you should unsubscribe from the offending channel
 | 
						|
(<command>nix-channel --remove
 | 
						|
<replaceable>URL</replaceable></command>; leave out
 | 
						|
<literal>/MANIFEST</literal>), and subscribe to the same URL, with
 | 
						|
<literal>channels</literal> replaced by <literal>channels-v3</literal>
 | 
						|
(e.g., <link
 | 
						|
xlink:href='http://catamaran.labs.cs.uu.nl/dist/nix/channels-v3/nixpkgs-unstable'
 | 
						|
/>).</para>
 | 
						|
 | 
						|
<para>Nix 0.8 has the following improvements:
 | 
						|
 | 
						|
<itemizedlist>
 | 
						|
 | 
						|
  <listitem><para>The cryptographic hashes used in store paths are now
 | 
						|
  160 bits long, but encoded in base-32 so that they are still only 32
 | 
						|
  characters long (e.g.,
 | 
						|
  <filename>/nix/store/csw87wag8bqlqk7ipllbwypb14xainap-atk-1.9.0</filename>).
 | 
						|
  (This is actually a 160 bit truncation of a SHA-256
 | 
						|
  hash.)</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>Big cleanups and simplifications of the basic store
 | 
						|
  semantics.  The notion of “closure store expressions” is gone (and
 | 
						|
  so is the notion of “successors”); the file system references of a
 | 
						|
  store path are now just stored in the database.</para>
 | 
						|
 | 
						|
  <para>For instance, given any store path, you can query its closure:
 | 
						|
 | 
						|
  <screen>
 | 
						|
$ nix-store -qR $(which firefox)
 | 
						|
... lots of paths ...</screen>
 | 
						|
 | 
						|
  Also, Nix now remembers for each store path the derivation that
 | 
						|
  built it (the “deriver”):
 | 
						|
 | 
						|
  <screen>
 | 
						|
$ nix-store -qR $(which firefox)
 | 
						|
/nix/store/4b0jx7vq80l9aqcnkszxhymsf1ffa5jd-firefox-1.0.1.drv</screen>
 | 
						|
 | 
						|
  So to see the build-time dependencies, you can do
 | 
						|
 | 
						|
  <screen>
 | 
						|
$ nix-store -qR $(nix-store -qd $(which firefox))</screen>
 | 
						|
 | 
						|
  or, in a nicer format:
 | 
						|
 | 
						|
  <screen>
 | 
						|
$ nix-store -q --tree $(nix-store -qd $(which firefox))</screen>
 | 
						|
 | 
						|
  </para>
 | 
						|
 | 
						|
  <para>File system references are also stored in reverse.  For
 | 
						|
  instance, you can query all paths that directly or indirectly use a
 | 
						|
  certain Glibc:
 | 
						|
 | 
						|
  <screen>
 | 
						|
$ nix-store -q --referrers-closure \
 | 
						|
    /nix/store/8lz9yc6zgmc0vlqmn2ipcpkjlmbi51vv-glibc-2.3.4</screen>
 | 
						|
 | 
						|
  </para>
 | 
						|
 | 
						|
  </listitem>
 | 
						|
 | 
						|
  <listitem><para>The concept of fixed-output derivations has been
 | 
						|
  formalised.  Previously, functions such as
 | 
						|
  <function>fetchurl</function> in Nixpkgs used a hack (namely,
 | 
						|
  explicitly specifying a store path hash) to prevent changes to, say,
 | 
						|
  the URL of the file from propagating upwards through the dependency
 | 
						|
  graph, causing rebuilds of everything.  This can now be done cleanly
 | 
						|
  by specifying the <varname>outputHash</varname> and
 | 
						|
  <varname>outputHashAlgo</varname> attributes.  Nix itself checks
 | 
						|
  that the content of the output has the specified hash.  (This is
 | 
						|
  important for maintaining certain invariants necessary for future
 | 
						|
  work on secure shared stores.)</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>One-click installation :-) It is now possible to
 | 
						|
  install any top-level component in Nixpkgs directly, through the web
 | 
						|
  — see, e.g., <link
 | 
						|
  xlink:href='http://catamaran.labs.cs.uu.nl/dist/nixpkgs-0.8/' />.
 | 
						|
  All you have to do is associate
 | 
						|
  <filename>/nix/bin/nix-install-package</filename> with the MIME type
 | 
						|
  <literal>application/nix-package</literal> (or the extension
 | 
						|
  <filename>.nixpkg</filename>), and clicking on a package link will
 | 
						|
  cause it to be installed, with all appropriate dependencies.  If you
 | 
						|
  just want to install some specific application, this is easier than
 | 
						|
  subscribing to a channel.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para><command>nix-store -r
 | 
						|
  <replaceable>PATHS</replaceable></command> now builds all the
 | 
						|
  derivations PATHS in parallel.  Previously it did them sequentially
 | 
						|
  (though exploiting possible parallelism between subderivations).
 | 
						|
  This is nice for build farms.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para><command>nix-channel</command> has new operations
 | 
						|
  <option>--list</option> and
 | 
						|
  <option>--remove</option>.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>New ways of installing components into user
 | 
						|
  environments:
 | 
						|
 | 
						|
  <itemizedlist>
 | 
						|
 | 
						|
    <listitem><para>Copy from another user environment:
 | 
						|
 | 
						|
    <screen>
 | 
						|
$ nix-env -i --from-profile .../other-profile firefox</screen>
 | 
						|
 | 
						|
    </para></listitem>
 | 
						|
 | 
						|
    <listitem><para>Install a store derivation directly (bypassing the
 | 
						|
    Nix expression language entirely):
 | 
						|
 | 
						|
    <screen>
 | 
						|
$ nix-env -i /nix/store/z58v41v21xd3...-aterm-2.3.1.drv</screen>
 | 
						|
 | 
						|
    (This is used to implement <command>nix-install-package</command>,
 | 
						|
    which is therefore immune to evolution in the Nix expression
 | 
						|
    language.)</para></listitem>
 | 
						|
 | 
						|
    <listitem><para>Install an already built store path directly:
 | 
						|
 | 
						|
    <screen>
 | 
						|
$ nix-env -i /nix/store/hsyj5pbn0d9i...-aterm-2.3.1</screen>
 | 
						|
 | 
						|
    </para></listitem>
 | 
						|
 | 
						|
    <listitem><para>Install the result of a Nix expression specified
 | 
						|
    as a command-line argument:
 | 
						|
 | 
						|
    <screen>
 | 
						|
$ nix-env -f .../i686-linux.nix -i -E 'x: x.firefoxWrapper'</screen>
 | 
						|
 | 
						|
    The difference with the normal installation mode is that
 | 
						|
    <option>-E</option> does not use the <varname>name</varname>
 | 
						|
    attributes of derivations.  Therefore, this can be used to
 | 
						|
    disambiguate multiple derivations with the same
 | 
						|
    name.</para></listitem>
 | 
						|
 | 
						|
  </itemizedlist></para></listitem>
 | 
						|
 | 
						|
  <listitem><para>A hash of the contents of a store path is now stored
 | 
						|
  in the database after a successful build.  This allows you to check
 | 
						|
  whether store paths have been tampered with: <command>nix-store
 | 
						|
  --verify --check-contents</command>.</para></listitem>
 | 
						|
 | 
						|
  <listitem>
 | 
						|
 | 
						|
    <para>Implemented a concurrent garbage collector.  It is now
 | 
						|
    always safe to run the garbage collector, even if other Nix
 | 
						|
    operations are happening simultaneously.</para>
 | 
						|
 | 
						|
    <para>However, there can still be GC races if you use
 | 
						|
    <command>nix-instantiate</command> and <command>nix-store
 | 
						|
    --realise</command> directly to build things.  To prevent races,
 | 
						|
    use the <option>--add-root</option> flag of those commands.</para>
 | 
						|
 | 
						|
  </listitem>
 | 
						|
 | 
						|
  <listitem><para>The garbage collector now finally deletes paths in
 | 
						|
  the right order (i.e., topologically sorted under the “references”
 | 
						|
  relation), thus making it safe to interrupt the collector without
 | 
						|
  risking a store that violates the closure
 | 
						|
  invariant.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>Likewise, the substitute mechanism now downloads
 | 
						|
  files in the right order, thus preserving the closure invariant at
 | 
						|
  all times.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>The result of <command>nix-build</command> is now
 | 
						|
  registered as a root of the garbage collector.  If the
 | 
						|
  <filename>./result</filename> link is deleted, the GC root
 | 
						|
  disappears automatically.</para></listitem>
 | 
						|
 | 
						|
  <listitem>
 | 
						|
 | 
						|
    <para>The behaviour of the garbage collector can be changed
 | 
						|
    globally by setting options in
 | 
						|
    <filename>/nix/etc/nix/nix.conf</filename>.
 | 
						|
 | 
						|
    <itemizedlist>
 | 
						|
 | 
						|
      <listitem><para><literal>gc-keep-derivations</literal> specifies
 | 
						|
      whether deriver links should be followed when searching for live
 | 
						|
      paths.</para></listitem>
 | 
						|
 | 
						|
      <listitem><para><literal>gc-keep-outputs</literal> specifies
 | 
						|
      whether outputs of derivations should be followed when searching
 | 
						|
      for live paths.</para></listitem>
 | 
						|
 | 
						|
      <listitem><para><literal>env-keep-derivations</literal>
 | 
						|
      specifies whether user environments should store the paths of
 | 
						|
      derivations when they are added (thus keeping the derivations
 | 
						|
      alive).</para></listitem>
 | 
						|
 | 
						|
    </itemizedlist>
 | 
						|
 | 
						|
  </para></listitem>
 | 
						|
 | 
						|
  <listitem><para>New <command>nix-env</command> query flags
 | 
						|
  <option>--drv-path</option> and
 | 
						|
  <option>--out-path</option>.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para><command>fetchurl</command> allows SHA-1 and SHA-256
 | 
						|
  in addition to MD5.  Just specify the attribute
 | 
						|
  <varname>sha1</varname> or <varname>sha256</varname> instead of
 | 
						|
  <varname>md5</varname>.</para></listitem>
 | 
						|
 | 
						|
  <listitem><para>Manual updates.</para></listitem>
 | 
						|
 | 
						|
</itemizedlist>
 | 
						|
 | 
						|
</para>
 | 
						|
 | 
						|
</section> |