Nix is a system for controlling the automatic creation and distribution of data, such as computer programs and other software artifacts. This is a very general problem, and there are many applications that fall under this description. Build management tools are used to perform software builds, that is, the construction of derived products such as executable programs from source code. A commonly used build tool is Make, which is a standard tool on Unix systems. These tools have to deal with several issues: After software has been built, is must also be deployed in the intended target environment, e.g., the user's workstation. Examples include the Red Hat package manager (RPM), Microsoft's MSI, and so on. Here also we have to deal with several issues: The creation of packages from some formal description of what artifacts should be distributed in the package. The deployment of packages, that is, the mechanism by which we get them onto the intended target environment. This can be as simple as copying a file, but complexity comes from the wide range of possible installation media (such as a network install), and the scalability of the process (if a program must be installed on a thousand systems, we do not want to visit each system and perform some manual steps to install the program on that system; that is, the complexity for the system administrator should be constant, not linear). ... Existing tools in this field generally both a underlying model (such as the derivation graph of build tools, or the versioning scheme that determines when two packages are compatible in a package management system) and a formalism that allows ... Following the principle of separation of mechanism and policy, the Nix system separates the low-level aspect of file system object management form the high-level aspect of the ... Bla bla Bla bla Bla bla Nix uses Sleepycat's Berkeley DB and CWI's ATerm library. However, these are fetched automatically as part of the build process. Other than that, you need a good C++ compiler. GCC 2.95 does not appear to work; please use GCC 3.x. Nix can be obtained from its Subversion repository. For example, the following command will check out the latest revision into a directory called nix: $ svn checkout http://losser.st-lab.cs.uu.nl:12080/repos/trace/nix/trunk nix Likewise, specific releases can be obtained from the tags directory of the repository. If you don't have Subversion, you can download a compressed tar-file of the latest revision of the repository. To build Nix, do the following: $ autoreconf -i $ ./configure options... $ make $ make install Currently, the only useful switch for configure is --prefix=prefix to specify where Nix is to be installed. The default installation directory is /nix. You can change this to any location you like. You should ensure that you have write permission to the installation prefix. It is advisable not to change the installation prefix, since doing so will in all likelihood make it impossible to use derivates built on other systems. nix manipulate or query the Nix store nix --path -p --verbose -v operation options arguments The command nix provides access to the Nix store. This is the (set of) path(s) where Nix expressions and the file system objects built by them are stored. nix has many subcommands called operations. These are individually documented below. Exactly one operation must always be provided. In this section the options that are common to all Nix operations are listed. These options are allowed for every subcommand (although they may not always have an effect). --path Indicates that any identifier arguments to the operation are paths in the store rather than identifiers. --verbose Increases the level of verbosity of diagnostic messages printed on standard error. For each Nix operation, the information printed on standard output is well-defined and specified below in the respective sections. Any diagnostic information is printed on standard error, never on standard output. This option may be specified repeatedly. Currently, the following verbosity levels exist: 0 Print error messages only. 1 Print informational messages. 2 Print even more informational messages. 3 Print messages that should only be useful for debugging. 4 Vomit mode: print vast amounts of debug information. nix --install -i ids The operation --install realises the Nix expressions identified by ids in the file system. If these expressions are derivation expressions, they are first normalised. That is, their target paths are are built, unless a normal form is already known. The identifiers of the normal forms of the given Nix expressions are printed on standard output. nix --delete -d paths The operation --delete unconditionally deletes the paths paths from the Nix store. It is an error to attempt to delete paths outside of the store. This operation should almost never be called directly, since no attempt is made to check whether any references exist to the paths to be deleted. Therefore, an inconsistent system could be the result. Deletion of paths in the store is done by the garbage collector (which uses --delete to delete unreferenced paths). If Nix or Fix appear to hang immediately after they are started, Nix's database is probably wedged, i.e., some process died while it held a lock on the database. The solution is to ensure that no other processes are accessing the database and then run the following command: $ db_recover -e -h prefix/var/nix/db Here, prefix should be replaced by Nix's installation prefix. Every time a Nix database transaction takes place, Nix writes a record of this transaction to a log in its database directory to ensure that the operation can be replayed in case of a application or system crash. However, without manual intervention, the log grows indefinitely. Hence, unused log files should be deleted periodically. This can be accomplished using the following command: $ rm `db_archive -a -h prefix/var/nix/db` Nix should automatically recover the Berkeley DB database. Nix should automatically remove Berkeley DB logfiles.