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@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev