keys to reference slice elements, e.g.,
Slice(["1ef7..."], [("/nix/store/1ef7...-foo", "1ef7", ["8c99..."]), ...])
This was wrong, since ids represent contents, not locations. Therefore we
now have:
Slice(["/nix/store/1ef7..."], [("/nix/store/1ef7...-foo", "1ef7", ["/nix/store/8c99-..."]), ...])
* Fix a bug in the computation of slice closures that could cause slice
elements to be duplicated.
value; this potentially dangerous feature enables better
sharing for those paths for which the content is known in
advance (e.g., because a content hash is given).
* Fast builds: if we can expand all output paths of a derive
expression, we don't have to build.
This is not entirely trivial since this introduces the possibility
of mutual recursion.
* Made normal forms self-contained.
* Use unique ids, not content hashes, for content referencing.
Unifying substitutes and successors isn't very feasible for now,
since substitutes are only used when no path with a certain is
known. Therefore, a normal form of some expression stored as a
substitute would not be used unless the expression itself was
missing.
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.
