[Nix-dev] Nix 1.2 released

[Eelco Dolstra]

Hi,

On 07/12/12 16:24, Marc Weber wrote:

>>   * Nix has a new binary substituter mechanism: the binary cache. A binary
>>     cache contains pre-built binaries of Nix packages. Whenever Nix wants to
>>     build a missing Nix store path, it will check a set of binary caches to see
>>     if any of them has a pre-built binary of that path. The configuration
>>     setting binary-caches contains a list of URLs of binary caches. For
>>     instance, doing
>>
>>     $ nix-env -i thunderbird --option binary-caches http://nixos.org/binary-cache
> Thus are non root users allowed to choose binary caches? 

Non-root users can only set binary-caches to a subset of the binary-caches and
trusted-binary-caches settings defined in nix.conf.  So you can't specify a
cache unless it was allowed by the admin.

>>     outputs = [ "lib" "headers" "doc" ];
>>     This will cause Nix to pass the intended store path of each output to the
>>     builder through the environment variables lib, headers and doc. Other
> 
> Which is kind of bad because LIB may be used by scripts - its too short.

So change your script... :-)  I mean, you could make the same argument about the
"out" variable.

>>   * Dashes are now valid as part of identifiers and attribute names.
> :)
> How to quote them using nix-env -A ?

"nix-env -A foo-bar" should just work (but I didn't test).

>>   * The new operation nix-store --repair-path allows corrupted or missing store
>>     paths to be repaired by redownloading them. nix-store --verify
>>     --check-contents --repair will scan and repair all paths in the Nix store.
>>     Similarly, nix-env, nix-build, nix-instantiate and nix-store --realise have
>>     a --repair flag to detect and fix bad paths by rebuilding or redownloading
>>     them.
> Can you be little bit more verbose about which risks you run doing so?
> Eg is it "atomic" or do you run the risk having a broken system for a
> short period of time?

There is a very brief time window in which the path is replaced with the new
contents (two rename() syscalls).  If that gets interrupted while repairing some
critical path (like Glibc) you might blow up your system.

>>     Nix will automatically make /nix/store writable as needed (using a private
>>     mount namespace) to allow modifications.
> This requires chroot builds, correct?

No.

>>   * Store optimisation (replacing identical files in the store with hard links)
>>     can now be done automatically every time a path is added to the store. This
>>     is enabled by setting the configuration option auto-optimise-store to true
>>     (disabled by default).
> Any experience about performance? Why is it disabled by default?

I had it enabled by default initially, but then I experienced some performance
hit on one machine so I disabled it for now.  Didn't have time to investigate it
more yet.

> I mean will this require reading all of /nix/store/* to find duplicate
> files even if all you do is installing a small tool into your path?

No, it keeps a index of all unique files in the store in /nix/store/.links keyed
by their cryptographic hashes, so it's efficient to look up whether a file with
particular contents already exists.

>>   * Chroot builds are now supported on systemd machines.
> 
> Have you also had time to think about supporting git hashes in addition
> to sha256 values? 

Yeah, I think that building support for specific version control systems into
Nix is rather ugly.  Next people will want Mercurial hashes, etc. etc.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/