depot - monorepo for the virus lounge

Age	Commit message (Collapse)	Author	Files	Lines
2006-03-06	* `nix-env (-i\|-u) --dry-run' now shows exactly which missing paths	Eelco Dolstra	1	-17/+0
	will be built or substituted.
2005-12-13	* Change `referer' to `referrer' throughout. In particular, the	Eelco Dolstra	1	-2/+3
	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).
2005-02-14	* It is now possible to add store derivations or paths directly to a	Eelco Dolstra	1	-0/+5
	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).
2005-01-25	* Maintain the references/referers relation also for derivations.	Eelco Dolstra	1	-19/+0
	This simplifies garbage collection and `nix-store --query --requisites' since we no longer need to treat derivations specially. * Better maintaining of the invariants, e.g., setReferences() can only be called on a valid/substitutable path.
2005-01-25	* In nix-store: added query `--referers-closure' that returns the	Eelco Dolstra	1	-2/+5
	closure of the referers relation rather than the references relation, i.e., the set of all paths that directly or indirectly refer to the given path. Note that contrary to the references closure this set is not fixed; it can change as paths are added to or removed from the store.
2005-01-20	* Terminology fixes.	Eelco Dolstra	1	-10/+10

2005-01-19	* Renamed `normalise.cc' -> `build.cc', `storeexprs.cc' ->	Eelco Dolstra	1	-0/+47
	`derivations.cc', etc. * Store the SHA-256 content hash of store paths in the database after they have been built/added. This is so that we can check whether the store has been messed with (a la `rpm --verify'). * When registering path validity, verify that the closure property holds.