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).
