* NEWS and manual update for release 0.7.
This commit is contained in:
parent
6af4a5a71f
commit
7d75616f2c
3 changed files with 41 additions and 1 deletions
22
NEWS
22
NEWS
|
@ -1,3 +1,25 @@
|
|||
Version 0.7
|
||||
|
||||
* Binary patching. When upgrading components using pre-built binaries
|
||||
(through nix-pull / nix-channel), Nix can automatically download and
|
||||
apply binary patches to already installed components instead of full
|
||||
downloads. Patching is "smart": if there is a *sequence* of patches
|
||||
to an installed component, Nix will use it. Patches are currently
|
||||
generated automatically between Nixpkgs (pre-)releases.
|
||||
|
||||
* Simplifications to the substitute mechanism.
|
||||
|
||||
* Nix-pull now stores downloaded manifests in /nix/var/nix/manifests.
|
||||
|
||||
* Metadata on files in the Nix store is canonicalised after builds:
|
||||
the last-modified timestamp is set to 0 (00:00:00 1/1/1970), the
|
||||
mode is set to 0444 or 0555 (readable and possibly executable by
|
||||
all; setuid/setgid bits are dropped), and the group is set to the
|
||||
default. This ensures that the result of a build and an
|
||||
installation through a substitute is the same; and that timestamp
|
||||
dependencies are revealed.
|
||||
|
||||
|
||||
Version 0.6
|
||||
|
||||
Major changes include the following:
|
||||
|
|
|
@ -75,7 +75,7 @@ be adapted easily to achieve similar policies.</para></listitem>
|
|||
|
||||
<listitem><para>Nix component builds aim to be <quote>pure</quote>;
|
||||
that is, unaffected by anything other than the declared dependencies.
|
||||
This means that if a component was built succesfully once, it can be
|
||||
This means that if a component was built successfully once, it can be
|
||||
rebuilt again on another machine and the result will be the same. We
|
||||
cannot <emphasis>guarantee</emphasis> this (e.g., if the build depends
|
||||
on the time-of-day), but Nix (and the tools in the Nix Packages
|
||||
|
@ -113,6 +113,13 @@ software deployment also apply here: for instance, the ability
|
|||
trivially to have multiple configurations at the same time, or the
|
||||
ability to do rollbacks.</para></listitem>
|
||||
|
||||
<listitem><para>Nix can efficiently upgrade between different versions
|
||||
of a component through <emphasis>binary patching</emphasis>. If
|
||||
patches are available on a server, and you try to install a new
|
||||
version of some component, Nix will automatically apply a patch (or
|
||||
sequence of patches), if available, to transform the installed
|
||||
component into the new version.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
|
|
@ -1253,6 +1253,17 @@ command-line argument. See <xref linkend='sec-standard-environment'
|
|||
performed by looking for the hash parts of file names of the
|
||||
inputs.</para></listitem>
|
||||
|
||||
<listitem><para>After the build, Nix sets the last-modified
|
||||
timestamp on all files in the build result to 0 (00:00:00 1/1/1970
|
||||
UTC), sets the group to the default group, and sets the mode of the
|
||||
file to 0444 or 0555 (i.e., read-only, with execute permission
|
||||
enabled if the file was originally executable). Note that possible
|
||||
<literal>setuid</literal> and <literal>setgid</literal> bits are
|
||||
cleared. Setuid and setgid programs are not currently supported by
|
||||
Nix. This is because the Nix archives used in deployment have no
|
||||
concept of ownership information, and because it makes the build
|
||||
result dependent on the user performing the build.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
|
Loading…
Reference in a new issue