(/nix/var/nix/daemon-socket). This allows access to the Nix daemon
to be restricted by setting the mode/ownership on that directory as
desired, e.g.
$ chmod 770 /nix/var/nix/daemon-socket
$ chown root.wheel /nix/var/nix/daemon-socket
to allow only users in the wheel group to use Nix.
Setting the ownership on a socket is much trickier, since the socket
must be deleted and recreated every time the daemon is started
(which would require additional Nix configuration file directives to
specify the mode/ownership, and wouldn't support arbitrary ACLs),
some BSD variants appear to ignore permissions on sockets, and it's
not clear whether the umask is respected on every platform when
creating sockets.
fixed-output derivations or substitutions try to build the same
store path at the same time. Locking generally catches this, but
not between multiple goals in the same process. This happened
especially often (actually, only) in the build farm with fetchurl
downloads of the same file being executed on multiple machines and
then copied back to the main machine where they would clobber each
other (NIXBF-13).
Solution: if a goal notices that the output path is already locked,
then go to sleep until another goal finishes (hopefully the one
locking the path) and try again.
derivations that produce the same output path don't work properly
wrt locking. This happens a lot in the build farm when fetchurl
derivations downloading the same file on different platforms are
executed in parallel and then copied back to the main machine.
manifests directory. In that case, we don't do a nix-pull, so the
user gets pure source deployment.
The directory /nix/var/nix/gcroots/per-user/$USER should be
writable. (It's created automatically if
/nix/var/nix/gcroots/per-user is writable, e.g. if it has 1777
permission.)
need any info on substitutable paths, we just call the substituters
(such as download-using-manifests.pl) directly. This means that
it's no longer necessary for nix-pull to register substitutes or for
nix-channel to clear them, which makes those operations much faster
(NIX-95). Also, we don't have to worry about keeping nix-pull
manifests (in /nix/var/nix/manifests) and the database in sync with
each other.
The downside is that there is some overhead in calling an external
program to get the substitutes info. For instance, "nix-env -qas"
takes a bit longer.
Abolishing the substitutes table also makes the logic in
local-store.cc simpler, as we don't need to store info for invalid
paths. On the downside, you cannot do things like "nix-store -qR"
on a substitutable but invalid path (but nobody did that anyway).
* Never catch interrupts (the Interrupted exception).
NIX_DOWNLOAD_CACHE is set, then nix-prefetch-url will store the hash
and timestamp of downloaded files in the directory
$NIX_DOWNLOAD_CACHE. This allows it to figure out if the file is
still in the Nix store.
;-)
* Channels: fix channels that are plain lists of derivations (like
strategoxt-unstable) instead of functions (like nixpkgs-unstable).
This fixes the error message "error: the left-hand side of the
function call is neither a function nor a primop (built-in
operation) but a list".
get the basename of the channel URL (e.g., nixpkgs-unstable). The
top-level Nix expression of the channel is now an attribute set, the
attributes of which are the individual channels (e.g.,
{nixpkgs_unstable = ...; strategoxt_unstable = ...}). This makes
attribute paths ("nix-env -qaA" and "nix-env -iA") more sensible,
e.g., "nix-env -iA nixpkgs_unstable.subversion".
by priority and version install. That is, if there are multiple
packages with the same name, then pick the package with the highest
priority, and only use the version if there are multiple packages
with the same priority.
This makes it possible to mark specific versions/variant in Nixpkgs
more or less desirable than others. A typical example would be a
beta version of some package (e.g., "gcc-4.2.0rc1") which should not
be installed even though it is the highest version, except when it
is explicitly selected (e.g., "nix-env -i gcc-4.2.0rc1").
* Idem for nix-env -u, only the semantics are a bit trickier since we
also need to take into account the priority of the currently
installed package (we never upgrade to a lower priority, unless
--always is given).
a user environment by an install or upgrade action. This is
particularly useful if you have a version installed that you don't
want to upgrade (e.g., because the newer versions are broken).
Example:
$ nix-env -u zapping --dry-run
(dry run; not doing anything)
upgrading `zapping-0.9.6' to `zapping-0.10cvs6'
$ nix-env --set-flag keep true zapping
$ nix-env -u zapping --dry-run
(dry run; not doing anything)
However, "-e" will still uninstall the package. (Maybe we should
require the keep flag to be explicitly set to false before it can be
uninstalled.)
user environment collission between two packages due to overlapping
file names, then a package with a higher priority will overwrite the
symlinks of a package with a lower priority. E.g.,
$ nix-env --set-flag priority 5 gcc
$ nix-env --set-flag priority 10 binutils
gives gcc a higher priority than binutils (higher number = lower
priority).
allow switching between them (NIX-80).
Example: two versions of Pan:
$ nix-env -q pan
pan-0.128
pan-0.14.2.91
$ readlink $(which pan)
/nix/store/l38jrbilw269drpjkx7kinhrxj6fjh59-pan-0.14.2.91/bin/pan
At most one of them can be active any given time. Assuming than
0.14.2.91 is active, you can active 0.128 as follows:
$ nix-env --set-flag active false pan-0.14.2.91
$ nix-env --set-flag active true pan-0.128
$ readlink $(which pan)
/nix/store/nziqwnlzy7xl385kglxhg75pfl5i936n-pan-0.128/bin/pan
More flags to follow.
to show only those derivations whose output is already in the Nix
store or that can be substituted (i.e., downloaded from somewhere).
In other words, it shows the packages that can be installed “quickly”,
i.e., don’t need to be built from source.
