target no longer applies to any available release. This is a
partial fix for NIX-34 (when producing linear patch sequences
between releases, the number of patches grows without bound).
useful way to transfer the closure of a store path to another
machine.
These commands provide functionality previously possible through
`nix-push --copy'. However, they are much more convenient in many
situations (though possibly less efficient).
Example:
$ nix-pack-closure /nix/store/hj232g1r...-subversion-1.3.0 > svn.closure
(on another machine:)
$ nix-unpack-closure < svn.closure
Note that Subversion is added to the store, but not installed into a
user environment. One should do `nix-env -i
/nix/store/hj232g1r...-subversion-1.3.0' for that.
Another example: copy the application Azureus to the machine
`scratchy' through ssh:
$ nix-pack-closure $(which azureus) | ssh scratchy nix-unpack-closure
nix-store query options `--referer' and `--referer-closure' have
been changed to `--referrer' and `--referrer-closure' (but the old
ones are still accepted for compatibility).
the parent runs before the child, it closes some pipe file
descriptors which causes the child to fail due to a bad file
descriptor. So we just use the normal open() function instead.
This fixes NIX-14 (intermittent nix-pull failures).
handle it. It crashed on the 234 MB tetex archive. Probably we
will never be able to handle archives of that size on 32-bit
machines (because bsdiff does everything in memory requiring
max(17*n,9*n+m)+O(1) bytes, so the address space simply isn't
there).
derivations. This is mostly to simplify the implementation of
nix-prefetch-{url, svn}, which now work properly in setuid
installations.
* Enforce valid store names in `nix-store --add / --add-fixed'.
occurances of a component. If the shortest path distance between a
component P and Q in the referers graph is D, then the contribution
of Q to the use of P is 1 / R^D, where R >= 1, typically 2. This
expresses that distant indirect uses are less important than nearby
uses.
For instance, this can disambiguate between the bootstrap GCC in
Nixpkgs and the GCC of the final stdenv (the former has more uses,
but they are further away), and between the GCC of the final stdenv
and the GCC+G77 build (the latter has very few uses).
by the build farm. See e.g.,
http://catamaran.labs.cs.uu.nl/dist/nixpkgs-0.8/nixpkgs-0.7pre2302/;
the user can click on packages, and they will be installed (assuming
the `application/nix-package' MIME type has been associated with
`nix-install-package').
Nix expressions are no longer involved: a "package" is just a
pointer to a manifest, and the top-level store derivation to be
added to the user environment. This makes these packages
independent from Nix expression evolution.
Note that we install the store derivation ($drvPath), not the
resulting output path ($outPath). This is equivalent, except that
installing the derivation maintains the back-link from the output
path to the derivation that built it. This is useful for
maintenance.
* Automatically re-exec in an xterm so that the user sees something
when `nix-install-package' is run from a browser.
too.
* Change the default hash for nix-prefetch-url back to md5, since
that's what we use in Nixpkgs (for now; a birthday attack is rather
unlikely there).
* Removed some dead code (successor stuff) from nix-push.
* Updated terminology in the tests (store expr -> drv path).
* Check that the deriver is set properly in the tests.
This was necessary becase root finding must be done after
acquisition of the global GC lock.
This makes `nix-collect-garbage' obsolete; it is now just a wrapper
around `nix-store --gc'.
* Automatically remove stale GC roots (i.e., indirect GC roots that
point to non-existent paths).
get rid of GC roots. Nix-build places a symlink `result' in the
current directory. Previously, removing that symlink would not
remove the store path being linked to as a GC root. Now, the GC
root created by nix-build is actually a symlink in
`/nix/var/nix/gcroots/auto' to `result'. So if that symlink is
removed the GC root automatically becomes invalid (since it can no
longer be resolved). The root itself is not automatically removed -
the garbage collector should delete dangling roots.
immediately add the result as a permanent GC root. This is the only
way to prevent a race with the garbage collector. For instance, the
old style
ln -s $(nix-store -r $(nix-instantiate foo.nix)) \
/nix/var/nix/gcroots/result
has two time windows in which the garbage collector can interfere
(by GC'ing the derivation and the output, respectively). On the
other hand,
nix-store --add-root /nix/var/nix/gcroots/result -r \
$(nix-instantiate --add-root /nix/var/nix/gcroots/drv \
foo.nix)
is safe.
* nix-build: use `--add-root' to prevent GC races.
roots to a per-process temporary file in /nix/var/nix/temproots
while holding a write lock on that file. The garbage collector
acquires read locks on all those files, thus blocking further
progress in other Nix processes, and reads the sets of temporary
roots.
though). In particular it's now much easier to register a GC root.
Just place a symlink to whatever store path it is that you want to
keep in /nix/var/nix/gcroots.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
files and hard-links them to each other to save disk space.
Currently it doesn't actually do the hard-linking, it just reports
the amount of space saved if it did.
substitute mechanism) creates a store path by downloading full NAR
archives and/or patches specified in the available manifests.
Any combination of present paths, full downloads, and patches can be
used to construct the target path. In particular, patches can be
chained in sequence; and full NAR archives of the target path can be
omitted (i.e., patch-only deployment is possible). A shortest path
algorithm is used to find the smallest set of files to be downloaded
(the edge weights are currently file sizes, but one can imagine
taking the network speed to the various source into account).
Patches are binary deltas between two store paths. To be precise,
they are the output of the `bsdiff' program applied to the NAR
archives obtained by dumping (`nix-store --dump') the two store
paths. The advantage of diff'ing NAR archives (and not, say, doing
file-by-file diffs) is that file renames/moves are handled
automatically. The disadvantage is that we cannot optimise creation
of unchanged files (by hard-linking).
unreachable paths that haven't been used for N hours. For instance,
`nix-collect-garbage --min-age 168' only deletes paths that haven't
been accessed in the last week.
This is useful for instance in the build farm where many derivations
can be shared between consecutive builds, and we wouldn't want a
garbage collect to throw them all away. We could of course register
them as roots, but then we'd to unregister them at some point, which
would be a pain to manage. The `--min-age' flag gives us a sort of
MRU caching scheme.
BUG: this really shouldn't be in gc.cc since that violates
mechanism/policy separation.
doesn't just print the set of paths that should be deleted. So
there is no more need to pipe the result into `nix-store --delete'
(which doesn't even exist anymore).
users.
If the configure flag `--enable-setuid' is used, the Nix programs
nix-env, nix-store, etc. are installed with the setuid bit turned on
so that they are executed as the user and group specified by
`--with-nix-user=USER' and `--with-nix-group=GROUP', respectively
(with defaults `nix' and `nix').
The setuid programs drop all special privileges if they are executed
by a user who is not a member of the Nix group.
The setuid feature is a quick hack to enable sharing of a Nix
installation between users who trust each other. It is not
generally secure, since any user in the Nix group can modify (by
building an appropriate derivation) any object in the store, and for
instance inject trojans into binaries used by other users.
The setuid programs are owned by root, not the Nix user. This is
because on Unix normal users cannot change the real uid, only the
effective uid. Many programs don't work properly when the real uid
differs from the effective uid. For instance, Perl will turn on
taint mode. However, the setuid programs drop all root privileges
immediately, changing all uids and gids to the Nix user and group.
