| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
I.e. do what git does. I'm too lazy to keep the builtin help text up
to date :-)
Also add ‘--help’ to various commands that lacked it
(e.g. nix-collect-garbage).
|
|
|
|
|
|
|
|
If we don't follow redirects, we might think that MANIFEST.bz2 exists
just because the HEAD request succeeds on the redirector URI.
|
|
|
|
read the manifest just to check the version and print the number of
paths. This makes nix-pull very fast for the cached cache (speeding
up nixos-rebuild without the ‘--no-pull’ or ‘--fast’ options).
|
|
disk space, and, since they're typically only decompressed once (to
fill the manifest cache), doesn't make things slower.
|
|
|
|
|
|
the Nix:: namespace.
|
|
if it doesn't exist.
|
|
location to DBI and DBD::SQLite can be passed with --with-dbi and
--with-dbd-sqlite.
|
|
and redundant anyway.
|
|
|
|
URL. This prevents lots of old cruft accumulating in
/nix/var/nix/manifests.
|
|
doesn't exist. The Debian packages don't include the manifests
directory, so nix-channel would silently skip doing a nix-pull,
resulting in everything being built from source. Thanks to Juan
Pedro Bolívar Puente.
|
|
|
|
|
|
|
|
|
|
|
|
need any info on substitutable paths, we just call the substituters
(such as download-using-manifests.pl) directly. This means that
it's no longer necessary for nix-pull to register substitutes or for
nix-channel to clear them, which makes those operations much faster
(NIX-95). Also, we don't have to worry about keeping nix-pull
manifests (in /nix/var/nix/manifests) and the database in sync with
each other.
The downside is that there is some overhead in calling an external
program to get the substitutes info. For instance, "nix-env -qas"
takes a bit longer.
Abolishing the substitutes table also makes the logic in
local-store.cc simpler, as we don't need to store info for invalid
paths. On the downside, you cannot do things like "nix-store -qR"
on a substitutable but invalid path (but nobody did that anyway).
* Never catch interrupts (the Interrupted exception).
|
|
try $url.bz2 first.
|
|
and store the manifests in the Nix store. (So now
/nix/var/nix/manifests/ just contains symlinks to the store and is
searched for GC roots.)
|
|
NIX_DOWNLOAD_CACHE is set, then nix-prefetch-url will store the hash
and timestamp of downloaded files in the directory
$NIX_DOWNLOAD_CACHE. This allows it to figure out if the file is
still in the Nix store.
|
|
path can be created by copying it from another location in the file
system. This is useful in the NixOS installation.
|
|
|
|
|
|
a different location than the user's. This makes channels usable as
a source deployment mechanism for people who install Nix under
non-standard prefixes. (NIX-57)
|
|
|
|
|
|
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).
|
|
|
|
|
|
* 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.
|
|
|
|
* Use force flag in `mv' to prevent silly interactive questions (this
happens with shared Nix stores).
|
|
|
|
invariant by registering references through the manifest.
* Added a test for nix-pull.
|
|
* Use the new patch downloader.
|
|
* Accept the NarHash line.
* Clear substitutes in `nix-channel --update'.
|
|
|
|
* Add /nix/var/nix/manifests directory.
|
|
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).
|
|
|
|
* Made the dependencies on bzip2 and the shell explicit.
|
