[Nix-dev] Nix 1.2 released

[Shea Levy]

On 12/07/2012 10:24 AM, Marc Weber wrote:
> Thank you all for those improvements
>>    * 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? Thereby they
> could download compromised binaries having the same store paths than the
> system might have ..
>
>>      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.
> I expect collisions. what about using out_lib out_headers
> out_doc ?
>
> I mean we want short names like .lib for installation, inspection and
> whatnot. I just don't think its a good idea to use those short names for
> env vars (especially the lib case).
>
>>    * Dashes are now valid as part of identifiers and attribute names.
> :)
> How to quote them using nix-env -A ?
>
>>    * 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?
>
>>      Nix will automatically make /nix/store writable as needed (using a private
>>      mount namespace) to allow modifications.
> This requires chroot builds, correct?
>
>>    * 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 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?
>
>>    * The command nix-copy-closure has a new flag --use-substitutes (-s) to
>>      download missing paths on the target machine using the substitute
>>      mechanism.
> cool ! I was happy reading about it.
>   
>>    * Chroot builds are now supported on systemd machines.
> Have you also had time to think about supporting git hashes in addition
> to sha256 values? For many dynamic things like getting packages from
> rubyforge, puypi etc you know the git commit hash, but not a sha256 or
> md5 value. Verifying such a store path would require running a git
> command and keeping the .git directory (so maybe you don't even need to
> checkout the files)
>
> And no, its not always an option to prefetch everything you may not need
> at all.

Can you maybe give a specific use-case here?

> Note that I don't ask you for implementing - just for sharing your
> thougts on the topic - and if - how you'd implement it.
>
> Marc Weber
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev