This relaxes restricted mode to allow access to anything in the store. In the future, it would be better to allow access to only paths that have been constructed in the current evaluation (so a hard-coded /nix/store/blabla in a Nix expression would still be rejected). However, note that reading /nix/store itself is still rejected, so you can't use this so get access to things you don't know about.
And don't try to delete generations from unwritable directories.
new generations if a generation already exists. Alternatively or additionally I propose a mode where only the *last* generation will be sparse.
For instance, you can install Firefox from a specific Nixpkgs revision like this: $ nix-env -f https://github.com/NixOS/nixpkgs/archive/63def04891a0abc328b1b0b3a78ec02c58f48583.tar.gz -iA firefox Or build a package from the latest nixpkgs-unstable channel: $ nix-build https://nixos.org/channels/nixpkgs-unstable/nixexprs.tar.xz -A hello
The call to nix-env expects a string which represents how old the derivations are or just "old" which means any generations other than the current one in use. Currently nix-collect-garbage passes an empty string to nix-env when using the -d option. This patch corrects the call to nix-env such that it follows the old behavior.
E.g. to install "hello" from the latest Nixpkgs: $ nix-build '<nixpkgs>' -A hello -I nixpkgs=https://nixos.org/channels/nixpkgs-unstable/nixexprs.tar.xz Or to install a specific version of NixOS: $ nixos-rebuild switch -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/63def04891a0abc328b1b0b3a78ec02c58f48583.tar.gz
The $channelName variable passed to the channel builder is the last portion of the URL and while that works in the previous test for channels prior to #519, it doesn't work if the last portion is nixexprs.tar.bz2. Signed-off-by: aszlig <firstname.lastname@example.org>
This hook can be used to set system-specific per-derivation build settings that don't fit into the derivation model and are too complex or volatile to be hard-coded into nix. Currently, the pre-build hook can only add chroot dirs/files through the interface, but it also has full access to the chroot root. The specific use case for this is systems where the operating system ABI is more complex than just the kernel-support system calls. For example, on OS X there is a set of system-provided frameworks that can reliably be accessed by any program linked to them, no matter the version the program is running on. Unfortunately, those frameworks do not necessarily live in the same locations on each version of OS X, nor do their dependencies, and thus nix needs to know the specific version of OS X currently running in order to make those frameworks available. The pre-build hook is a perfect mechanism for doing just that.