| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
by Rob).
|
|
|
|
|
|
listed later in the list of new valid paths.
|
|
|
|
`--register-validity'.
* `nix-store --register-validity': read arguments from stdin, and
allow the references and deriver to be set.
|
|
|
|
expressions.
|
|
|
|
* Maintain the cleanup invariant in clearSubstitutes().
|
|
store path (which is stored in the database).
|
|
continue building when one fails unless `--keep-going' is
specified.
* When `--keep-going' is specified, print out the set of failing
derivations at the end (otherwise it can be hard to find out which
failed).
|
|
NAR dump of the path).
|
|
in `fetchurl' in Nix <= 0.7, but doesn't in Nix 0.8.
|
|
multiple times is also a top-level goal, then the second and later
instantiations would never be created because there would be a
stable pointer to the first one that would keep it alive in the
WeakGoalMap.
* Some tracing code for debugging this kind of problem.
|
|
of the given derivation. Useful for getting a quick overview of how
something was built. E.g., to find out how the `baffle' program in
your user environment was built, you can do
$ nix-store -q --tree $(nix-store -qd $(which baffle))
Tree nesting depth is minimised (?) by topologically sorting paths
under the relation A < B iff A \in closure(B).
|
|
|
|
setuid installation.
|
|
|
|
|
|
environment elements from one user environment to another, e.g.,
$ nix-env -i --from-profile /nix/var/nix/profiles/other-profile aterm
copies the `aterm' component installed in the `other-profile' to the
user's current profile.
|
|
user environment, e.g.,
$ nix-env -i /nix/store/z58v41v21xd3ywrqk1vmvdwlagjx7f10-aterm-2.3.1.drv
or
$ nix-env -i /nix/store/hsyj5pbn0d9iz7q0aj0fga7cpaadvp1l-aterm-2.3.1
This is useful because it allows Nix expressions to be bypassed
entirely. For instance, if only a nix-pull manifest is provided,
plus the top-level path of some component, it can be installed
without having to supply the Nix expression (e.g., for obfuscation,
or to be independent of Nix expression language changes or context
dependencies).
|
|
install derivations from a Nix expression specified on the command
line. This is particularly useful for disambiguation if there are
multiple derivations with the same name. For instance, in Nixpkgs,
to install the Firefox wrapper rather than the plain Firefox
component:
$ nix-env -f .../i686-linux.nix -i -E 'x: x.firefoxWrapper'
The Nix expressions should be functions to which the default Nix
expression (in this case, `i686-linux.nix') is passed, hence `x:
...'.
This might also be a nice way to deal with high-level (user-level)
variability, e.g.,
$ nix-env -f ./server.nix -i -E 'x: x {port = 8080; ssl = false;}'
|
|
|
|
|
|
to derivations in user environments. Nice for developers (since it
prevents build-time-only dependencies from being GC'ed, in
conjunction with `gc-keep-outputs'). Turned off by default.
|
|
|
|
|
|
* Set the references for the user environment manifest properly.
* Don't copy the manifest (this was accidental).
* Don't store derivation paths in the manifest (maybe this should be
made optional). This cleans up the semantics of nix-env, which were
weird.
* Hash on the output paths of activated components, not on derivation
paths. This is because we don't know the derivation path of already
installed components anymore, and it allows the installation of
components by store path (skipping Nix expressions entirely).
* Query options `--out-path' and `--drv-path' to show the output and
derivation paths of components, respectively (the latter replaces
the `--expr' query).
|
|
|
|
|
|
* 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.
|
|
existing user environments continue to work).
* `nix-store --verify': detect incomplete closures.
|
|
that the contents of store paths has not changed by comparing hashes
of their current contents to the hashes stored in the database.
|
|
|
|
for finding build-time dependencies (possibly after a build). E.g.,
$ nix-store -qb aterm $(nix-store -qd $(which strc))
/nix/store/jw7c7s65n1gwhxpn35j9rgcci6ilzxym-aterm-2.3.1
* Arguments to nix-store can be files within store objects, e.g.,
/nix/store/jw7c...-aterm-2.3.1/bin/baffle.
* Idem for garbage collector roots.
|
|
derivation that produced them.
* `nix-store -qd PATH' prints out the derivation that produced a path.
|
|
derivations should be kept.
|
|
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.
|
|
* Fix GC and substitute bugs related to self-references. Add a
regression test.
|
|
being created after the garbage collector has read the temproots
directory. This blocks the creation of new processes, but the
garbage collector could periodically release the GC lock to allow
them to run.
|
|
temporary root files have been read but creating outputs before the
store directory has been read.
|
|
|
|
that they are deleted in an order that maintains the closure
invariant.
* Presence of a path in a temporary roots file does not imply that all
paths in its closure are also present, so add the closure.
|
|
|
