it only does something if $NIX_OTHER_STORES (not really a good
name...) is set.
* Do globbing on the elements of $NIX_OTHER_STORES. E.g. you could
set it to /mnts/*/nix or something.
* Install substituters in libexec/nix/substituters.
stores (typically remote Nix stores mounted via e.g. NFS, or the Nix
store on the NixOS installation CD). Example use:
$ sshfs foo@example.org:/ /mnt
$ NIX_OTHER_STORES=/mnt/nix \
NIX_SUBSTITUTERS=.../copy-from-other-stores.pl \
nix-env -i foo
This will be especially useful for the installation CD since it
doesn't require a manifest for the CD contents.
another machine through ssh. E.g.,
$ nix-copy-closure xyzzy $(which svn)
copies the closure of Subversion to machine `xyzzy'. This is like
`nix-pack-closure $(which svn) | ssh xyzzy', but it's much more
efficient since it only copies those paths that are missing on the
target machine.
such as open files, current directories, mmaped files, etc. This is
inherently unportable, but it's easy to adapt this script to other
platforms. Currently we call `lsof' and try to read various bits in
/proc/NNN.
The goal is to prevent the garbage collector from removing store
paths that are no longer reachable from a permanent root but that
are still in use (for instance, after the user has done "nix-env -e"
on a running program).
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 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.
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/.
hash for which no local expansion is available, Nix can execute a
`substitute' which should produce a path with such a hash.
This is policy-free since Nix does not in any way specify how the
substitute should work, i.e., it's an arbitrary (unnormalised)
fstate expression. For example, `nix-pull' registers substitutes
that fetch Nix archives from the network (through `wget') and unpack
them, but any other method is possible as well. This is an
improvement over the old Nix sharing scheme, which had a policy
(fetching through `wget') built in.
The sharing scheme doesn't work completely yet because successors
from fstate rewriting have to be registered on the receiving side.
Probably the whole successor stuff can be folded up into the
substitute mechanism; this would be a nice simplification.
archives (using the package in corepkgs/nar).
* queryPathByHash -> expandHash, and it takes an argument specifying
the target path (which may be empty).
* Install the core Fix packages in $prefix/share/fix. TODO: bootstrap
Nix and install Nix as a Fix package.
a mapping from the hash to a url has been registered through `nix
regurl'.
* Bug fix in nix: don't pollute stdout when running tar, it made
nix-switch barf.
* Bug fix in nix-push-prebuilts: don't create a subdirectory on the
target when rsync'ing.
sharing package directories (i.e., the result of building a Nix
descriptor).
`nix-pull-prebuilts' obtains a list of all known prebuilts by
consulting the paths and URLs specified in
$prefix/etc/nix/prebuilts.conf. The mappings ($pkghash,
$prebuilthash) and ($prebuilthash, $location) are registered with
Nix so that it can use the prebuilt with hash $prebuilthash when
installing a package with hash $pkghash by downloading and unpacking
$location.
`nix-push-prebuilts' creates prebuilts for all packages for which no
prebuilt is known to exist. It can then optionally upload these
to the network through rsync.
`nix-[pull|push]-prebuilts' just provide a policy. Nix provides the
mechanism through the `nix [export|regprebuilt|regurl]' commands.
doesn't actually delete any packages, it just prints their
descriptor hashes. So we can do
nix info $(nix-collect-garbage)
to print out the ids of the packages that would be deleted, and
nix delpkg $(nix-collect-garbage)
to actually delete them.
build action for `system' packages (like system.fix) that have
dependencies on all packages we want to activate.
So the command sequence to switch to a new activation configuration
of the system would be:
$ fix -i .../fixdescriptors/system.fix
...
system.fix -> 89cf4713b37cc66989304abeb9ea189f
$ nix-switch 89cf4713b37cc66989304abeb9ea189f
* A nix-profile.sh script that can be included in .bashrc.
Eelco Dolstra
Michael Raskin