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.
Nix expressions.
To subscribe to a channel (needs to be done only once):
nix-channel --add \
http://catamaran.labs.cs.uu.nl/dist/nix/channels/nixpkgs-unstable
This just adds the given URL to ~/.nix-channels (which can also be
edited manually).
To update from all channels:
nix-channel --update
This fetches the latest expressions and pulls cache manifests. The
default Nix expression (~/.nix-defexpr) is made to point to the
conjunction of the expressions downloaded from all channels.
So to update all installed derivations in the current user
environment:
nix-channel --update
nix-env --upgrade '*'
If you are really courageous, you can put this in a cronjob or
something.
You can subscribe to multiple channels. It is not entirely clear
what happens when there are name clashes between derivations from
different channels. From nix-env/main.cc it appears that the one
with the lowest (highest?) hash will be used, which is pretty
meaningless.
environment variable. This is useful for passing authentication
information (it won't show up in `ps'). Hacky - nix-push should
abstract over the use of Curl.
default -> default-94-link
default-82-link -> /nix/store/cc4480...
default-83-link -> /nix/store/caeec8...
...
default-94-link -> /nix/store/2896ca...
experimental -> experimental-2-link
experimental-1-link -> /nix/store/cc4480...
experimental-2-link -> /nix/store/a3148f...
* `--profile' / `-p' -> `--switch-profile' / `-S'
* `--link' / `-l' -> `--profile' / `-p'
* The default profile is stored in $prefix/var/nix/profiles.
$prefix/var/nix/links is gone. Profiles can be stored anywhere.
* The current profile is now referenced from ~/.nix-profile, not
~/.nix-userenv.
* The roots to the garbage collector now have extension `.gcroot', not
`.id'.
the symlink ~/.nix-userenv to the given argument (which defaults to
.../links/current). /etc/profile.d/nix-profile creates this symlink
if it doesn't exist yet. Example use:
$ nix-env -l my_profile -i foo.nix subversion quake
$ nix-env -p my_profile
I don't like the term "profile". Let's deprecate it :-)
The script nix-install-package takes a `Nix package file' (which
contains one or more derivations, along with URLs of Nix caches),
unpacks it, pulls the caches, and installs the derivations in the
user's environment.
For best results, associate the command `xterm -e
/nix/bin/nix-install-package' with the MIME type
`application/x-nix-package' and visit
http://losser.st-lab.cs.uu.nl/~eelco/test/.
* Fixed a segfault caused by the buffering of stderr.
* Fix now allows the specification of the full output path. This
should be used with great care, since it by-passes the normal hash
generation.
* Incremented the version number to 0.4 (prerelease).
NAME'. E.g., on the losser Subversion server, I do `nix-switch --name
svn $(fix ...)' to atomically upgrade the server (the SVN server
uses the Apache and Subversion installations in /nix/var/nix/links/svn).
Renamed `fstateRefs' to `fstateRequisites'. The semantics of this
function is that it returns a list of all paths necessary to realise
a given expression. For a derive expression, this is the union of
requisites of the inputs; for a slice expression, it is the path of
each element in the slice. Also included are the paths of the
expressions themselves. Optionally, one can also include the
requisites of successor expressions (to recycle intermediate
results).
* `nix-switch' now distinguishes between an expression and its normal
form. Usually, only the normal form is registered as a root of the
garbage collector. With the `--source-root' flag, it will also
register the original expression as a root.
* `nix-collect-garbage' now has a flag `--keep-successors' which
causes successors not to be included in the list of garbage paths.
* `nix-collect-garbage' now has a flag `--invert' which will print all
paths that should *not* be garbage collected.
dynamically links against libdb4 (?!), due to LD_LIBRARY_PATH it picks
up our libdb4 instead of SuSE's libdb4, but our libdb4 uses another
glibc so loading barfs.
Instead, all packages should use rpaths to store library locations in
executables/libraries. The disadvantage is that overriding rpaths is
harder. (It is possible by invoking the dynamic linker directly, e.g.,
`/lib/ld-linux.so.2 --ignore-path LIST program args...' to ignore the
rpath for the libraries in LIST). It would be better to use DT_RUNPATH,
which is consulted by the dynamic linker *after* LD_LIBRARY_PATH but
*before* ld.so.cache and the system directories.
substituting for (obvious, really).
* For greater efficiency, nix-pull/unnar will place the output in a
path that is probably the same as what is actually needed, thus
preventing a path copy.
* Even if a output id is given in a Fix package expression, ensure
that the resulting Nix derive expression has a different id. This
is because Nix expressions that are semantically equivalent (i.e.,
build the same result) might be different w.r.t. efficiency or
divergence. It is absolutely vital for the substitute mechanism
that such expressions are not used interchangeably.
number of bytes, e.g., in case of a signal like SIGSTOP.
This caused `nix --dump' to fail sometimes.
Note that this bug went unnoticed because the call to `nix
--dump' is in a pipeline, and the shell ignores non-zero
exit codes from all but the last element in the pipeline.
Is there any way to check the result of the initial elements
in the pipeline? (In other words, is it at all possible to
write reliable shell scripts?)
