diff --git a/doc/manual/build-farm.xml b/doc/manual/build-farm.xml index cfca63f36..9a6345896 100644 --- a/doc/manual/build-farm.xml +++ b/doc/manual/build-farm.xml @@ -36,10 +36,10 @@ build farm, since: builds, and Nix expressions are self-contained. Nix will only rebuild things that have actually - changed. For instance, if the sources of a component haven't - changed between runs of the build farm, the component won't be - rebuild (unless it was garbage-collected). Also, dependencies - typically don't change very often, so they only need to be built + changed. For instance, if the sources of a package haven't changed + between runs of the build farm, the package won't be rebuilt (unless + it was garbage-collected). Also, dependencies typically don't + change very often, so they only need to be built once. The results of a Nix build farm can be made diff --git a/doc/manual/glossary.xml b/doc/manual/glossary.xml index e76f99a26..efbf96f0a 100644 --- a/doc/manual/glossary.xml +++ b/doc/manual/glossary.xml @@ -74,9 +74,9 @@ Nix expression - A high-level description of software components and + A high-level description of software packages and compositions thereof. Deploying software using Nix entails writing - Nix expressions for your components. Nix expressions are translated + Nix expressions for your packages. Nix expressions are translated to derivations that are stored in the Nix store. These derivations can then be built. diff --git a/doc/manual/installation.xml b/doc/manual/installation.xml index 72e4b541a..d61c0c230 100644 --- a/doc/manual/installation.xml +++ b/doc/manual/installation.xml @@ -42,9 +42,8 @@ platforms as well.
Obtaining Nix The easiest way to obtain Nix is to download a source -distribution. RPMs for Red Hat, SuSE, and Fedora Core are also -available. +xlink:href="http://nix.cs.uu.nl/">source distribution. RPMs +for Red Hat, SuSE, and Fedora Core are also available. Alternatively, the most recent sources of Nix can be obtained from its
Installing from RPMs -RPM packages of Nix can be downloaded from http://www.cs.uu.nl/groups/ST/Trace/Nix. -These RPMs should work for most fairly recent releases of SuSE and Red -Hat Linux. They have been known to work work on SuSE Linux 8.1 and -9.0, and Red Hat 9.0. In fact, it should work on any RPM-based Linux -distribution based on glibc 2.3 or later. +RPM packages of Nix can be downloaded from . These RPMs should work for most +fairly recent releases of SuSE and Red Hat Linux. They have been +known to work work on SuSE Linux 8.1 and 9.0, and Red Hat 9.0. In +fact, it should work on any RPM-based Linux distribution based on +glibc 2.3 or later. Once downloaded, the RPMs can be installed or upgraded using rpm -U. For example, diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml index 7f7cd11d5..d2f23bf44 100644 --- a/doc/manual/introduction.xml +++ b/doc/manual/introduction.xml @@ -50,7 +50,7 @@ are complete. In general, when you’re making a package for a package management system like RPM, you have to specify for each package what its dependencies are, but there are no guarantees that this specification is complete. If you forget a dependency, then the -component will build and work correctly on your +package will build and work correctly on your machine if you have the dependency installed, but not on the end user's machine if it's not there. diff --git a/doc/manual/nix-env.xml b/doc/manual/nix-env.xml index 9af8c0c02..a0ec489fd 100644 --- a/doc/manual/nix-env.xml +++ b/doc/manual/nix-env.xml @@ -48,7 +48,7 @@ Description The command nix-env is used to manipulate Nix -user environments. User environments are sets of software components +user environments. User environments are sets of software packages available to a user at some point in time. In other words, they are a synthesised view of the programs available in the Nix store. There may be many user environments: different users can have different @@ -750,35 +750,35 @@ user environment elements, etc. --> Compare installed versions to available versions, or vice versa (if is given). This is useful for quickly seeing whether upgrades for installed - components are available in a Nix expression. A column is added + packages are available in a Nix expression. A column is added with the following meaning: < version - A newer version of the component is available + A newer version of the package is available or installed. = version - At most the same version of the component is + At most the same version of the package is available or installed. > version - Only older versions of the component are + Only older versions of the package are available or installed. - ? - No version of the component is available or + No version of the package is available or installed. diff --git a/doc/manual/package-management.xml b/doc/manual/package-management.xml index a24ca0a69..9ab181692 100644 --- a/doc/manual/package-management.xml +++ b/doc/manual/package-management.xml @@ -6,9 +6,9 @@ This chapter discusses how to do package management with Nix, -i.e., how to obtain, install, upgrade, and erase components. This is +i.e., how to obtain, install, upgrade, and erase packages. This is the “user’s” perspective of the Nix system — people -who want to create components should consult +who want to create packages should consult . @@ -16,8 +16,8 @@ who want to create components should consult The main command for package management is nix-env. You can use -it to install, upgrade, and erase components, and to query what -components are installed or are available for installation. +it to install, upgrade, and erase packages, and to query what +packages are installed or are available for installation. In Nix, different users can have different “views” on the set of installed applications. That is, there might be lots of @@ -30,10 +30,10 @@ environment, which is just a directory tree consisting of symlinks to the files of the active applications. Components are installed from a set of Nix -expressions that tell Nix how to build those components, +expressions that tell Nix how to build those packages, including, if necessary, their dependencies. There is a collection of Nix expressions called the Nix Package collection that contains -components ranging from basic development stuff such as GCC and Glibc, +packages ranging from basic development stuff such as GCC and Glibc, to end-user applications like Mozilla Firefox. (Nix is however not tied to the Nix Package collection; you could write your own Nix expressions based on it, or completely new ones.) You can download @@ -41,7 +41,7 @@ the latest version from . Assuming that you have downloaded and unpacked a release of Nix -Packages, you can view the set of available components in the release: +Packages, you can view the set of available packages in the release: $ nix-env -qaf nixpkgs-version '*' @@ -74,7 +74,7 @@ gcc-4.1.1 It is also possible to see the status of -available components, i.e., whether they are installed into the user +available packages, i.e., whether they are installed into the user environment and/or present in the system: @@ -86,24 +86,24 @@ IPS bison-1.875d ... The first character (I) indicates whether the -component is installed in your current user environment. The second +package is installed in your current user environment. The second (P) indicates whether it is present on your system (in which case installing it into your user environment would be a very quick operation). The last one (S) indicates whether there is a so-called substitute for the -component, which is Nix’s mechanism for doing binary deployment. It -just means that Nix knows that it can fetch a pre-built component from +package, which is Nix’s mechanism for doing binary deployment. It +just means that Nix knows that it can fetch a pre-built package from somewhere (typically a network server) instead of building it locally. So now that we have a set of Nix expressions we can build the -components contained in them. This is done using nix-env +packages contained in them. This is done using nix-env -i. For instance, $ nix-env -f nixpkgs-version -i subversion -will install the component called subversion (which +will install the package called subversion (which is, of course, the Subversion version management system). @@ -112,7 +112,7 @@ management system). Subversion and all its dependencies. This will take quite a while — typically an hour or two on modern machines. Fortunately, there is a faster way (so do a Ctrl-C on that install operation!): you just need -to tell Nix that pre-built binaries of all those components are +to tell Nix that pre-built binaries of all those packages are available somewhere. This is done using the nix-pull command, which must be supplied with a URL containing a manifest describing what binaries @@ -153,7 +153,7 @@ expressions, use -i instead of -u; -i will remove whatever version is already installed. -You can also upgrade all components for which there are newer +You can also upgrade all packages for which there are newer versions: @@ -199,19 +199,19 @@ set. implementing the ability to allow different users to have different configurations, and to do atomic upgrades and rollbacks. To understand how they work, it’s useful to know a bit about how Nix -works. In Nix, components are stored in unique locations in the +works. In Nix, packages are stored in unique locations in the Nix store (typically, /nix/store). For instance, a particular version -of the Subversion component might be stored in a directory +of the Subversion package might be stored in a directory /nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3/, while another version might be stored in /nix/store/5mq2jcn36ldlmh93yj1n8s9c95pj7c5s-subversion-1.1.2. The long strings prefixed to the directory names are cryptographic hashes160-bit truncations of SHA-256 hashes encoded in a base-32 notation, to be precise. of -all inputs involved in building the component — +all inputs involved in building the package — sources, dependencies, compiler flags, and so on. So if two -components differ in any way, they end up in different locations in +packages differ in any way, they end up in different locations in the file system, so they don’t interfere with each other. shows a part of a typical Nix store. @@ -231,12 +231,12 @@ $ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn every time you want to run Subversion. Of course we could set up the PATH environment variable to include the -bin directory of every component we want to use, +bin directory of every package we want to use, but this is not very convenient since changing PATH doesn’t take effect for already existing processes. The solution Nix uses is to create directory trees of symlinks to -activated components. These are called -user environments and they are components +activated packages. These are called +user environments and they are packages themselves (though automatically generated by nix-env), so they too reside in the Nix store. For instance, in the user @@ -285,8 +285,8 @@ operation, a new user environment and generation link are created based on the current one, and finally the default symlink is made to point at the new generation. This last step is atomic on Unix, which explains how we can do atomic upgrades. (Note -that the building/installing of new components doesn’t interfere in -any way with old components, since they are stored in different +that the building/installing of new packages doesn’t interfere in +any way with old packages, since they are stored in different locations in the Nix store.) If you find that you want to undo a nix-env @@ -352,18 +352,18 @@ This will not change the nix-env operations such as upgrades () and uninstall () never -actually delete components from the system. All they do (as shown +actually delete packages from the system. All they do (as shown above) is to create a new user environment that no longer contains -symlinks to the “deleted” components. +symlinks to the “deleted” packages. -Of course, since disk space is not infinite, unused components +Of course, since disk space is not infinite, unused packages should be removed at some point. You can do this by running the Nix -garbage collector. It will remove from the Nix store any component +garbage collector. It will remove from the Nix store any package not used (directly or indirectly) by any generation of any profile. Note however that as long as old generations reference a -component, it will not be deleted. After all, we wouldn’t be able to +package, it will not be deleted. After all, we wouldn’t be able to do a rollback otherwise. So in order for garbage collection to be effective, you should also delete (some) old generations. Of course, this should only be done if you are certain that you will not need to @@ -486,7 +486,7 @@ makes the union of each channel’s Nix expressions the default for $ nix-env -u '*' -to upgrade all components in your profile to the latest versions +to upgrade all packages in your profile to the latest versions available in the subscribed channels.
diff --git a/doc/manual/quick-start.xml b/doc/manual/quick-start.xml index c4065ace1..b51f2b167 100644 --- a/doc/manual/quick-start.xml +++ b/doc/manual/quick-start.xml @@ -11,7 +11,7 @@ to the following chapters. Download a source tarball or RPM from . Build source +xlink:href='http://nix.cs.uu.nl/'/>. Build source distributions using the regular sequence: @@ -22,8 +22,9 @@ $ make install (as root) This will install Nix in /nix. You shouldn't change the prefix if at all possible since that will make it -impossible to use our pre-built components. Alternatively, you could -grab an RPM if you're on an RPM-based system. You should also add +impossible to use pre-built binaries from the Nixpkgs channel and +other channels. Alternatively, you could grab an RPM if you're on an +RPM-based system. You should also add /nix/etc/profile.d/nix.sh to your ~/.bashrc (or some other login file). @@ -40,14 +41,14 @@ $ nix-channel --add \ $ nix-channel --update -Note that this in itself doesn't download any components, it just +Note that this in itself doesn't download any packages, it just downloads the Nix expressions that build them and stores them somewhere (under ~/.nix-defexpr, in case you're curious). Also, it registers the fact that pre-built binaries are available remotely. -See what installable components are currently -available in the channel: +See what installable packages are currently available +in the channel: $ nix-env -qa ’*’ (mind the quotes!) @@ -59,13 +60,13 @@ libxslt-1.1.0 -Install some components from the channel: +Install some packages from the channel: $ nix-env -i hello firefox ... -This should download the pre-built components; it should not build -them locally (if it does, something went wrong). +This should download pre-built packages; it should not build them +locally (if it does, something went wrong). Test that they work: @@ -92,8 +93,8 @@ $ nix-env -e hello $ nix-channel --update $ nix-env -u '*' -The latter command will upgrade each installed component for which -there is a “newer” version (as determined by comparing the version +The latter command will upgrade each installed package for which there +is a “newer” version (as determined by comparing the version numbers). You can also install specific packages directly from @@ -107,7 +108,7 @@ appear asking you whether it’s okay to install the package. Say installed. If you're unhappy with the result of a -nix-env action (e.g., an upgraded component turned +nix-env action (e.g., an upgraded package turned out not to work properly), you can go back: @@ -124,7 +125,7 @@ $ nix-collect-garbage -d diff --git a/doc/manual/writing-nix-expressions.xml b/doc/manual/writing-nix-expressions.xml index 5fa9e423d..54108e9cf 100644 --- a/doc/manual/writing-nix-expressions.xml +++ b/doc/manual/writing-nix-expressions.xml @@ -7,7 +7,7 @@ This chapter shows you how to write Nix expressions, which are -the things that tell Nix how to build components. It starts with a +the things that tell Nix how to build packages. It starts with a simple example (a Nix expression for GNU Hello), and then moves on to a more in-depth look at the Nix expression language. @@ -19,29 +19,28 @@ xlink:href='http://www.gnu.org/software/hello/hello.html'>GNU Hello package to the Nix Packages collection. Hello is a program that prints out the text Hello, world!. -To add a component to the Nix Packages collection, you generally +To add a package to the Nix Packages collection, you generally need to do three things: - Write a Nix expression for the component. This is a - file that describes all the inputs involved in building the - component, such as dependencies (other components required by the - component), sources, and so on. + Write a Nix expression for the package. This is a + file that describes all the inputs involved in building the package, + such as dependencies, sources, and so on. Write a builder. This is a shell scriptIn fact, it can be written in any language, but typically it's a bash shell - script. that actually builds the component from + script. that actually builds the package from the inputs. - Add the component to the file + Add the package to the file pkgs/top-level/all-packages.nix. The Nix expression written in the first step is a - function; it requires other components in order + function; it requires other packages in order to build it. In this step you put it all together, i.e., you call the function with the right arguments to build the actual - component. + package. @@ -83,8 +82,8 @@ the single Nix expression in that directory arguments: stdenv, fetchurl, and perl. They are needed to build Hello, but we don't know how to build them here; that's why they are function - arguments. stdenv is a component that is used - by almost all Nix Packages components; it provides a + arguments. stdenv is a package that is used + by almost all Nix Packages packages; it provides a standard environment consisting of the things you would expect in a basic Unix environment: a C/C++ compiler (GCC, to be precise), the Bash shell, fundamental Unix tools such as @@ -99,19 +98,19 @@ the single Nix expression in that directory e is the body of the function. So here, the entire remainder of the file is the body of the function; when given the required arguments, the body should - describe how to build an instance of the Hello component. + describe how to build an instance of the Hello package. - So we have to build a component. Building something from + So we have to build a package. Building something from other stuff is called a derivation in Nix (as opposed to sources, which are built by humans instead of computers). We perform a derivation by calling stdenv.mkDerivation. mkDerivation is a function provided by - stdenv that builds a component from a set of + stdenv that builds a package from a set of attributes. An attribute set is just a list of key/value pairs where each value is an arbitrary Nix expression. They take the general form @@ -125,10 +124,10 @@ the single Nix expression in that directory The attribute name specifies the symbolic - name and version of the component. Nix doesn't really care about + name and version of the package. Nix doesn't really care about these things, but they are used by for instance nix-env -q to show a human-readable name for - components. This attribute is required by + packages. This attribute is required by mkDerivation. @@ -149,7 +148,7 @@ the single Nix expression in that directory - The builder has to know what the sources of the component + The builder has to know what the sources of the package are. Here, the attribute src is bound to the result of a call to the fetchurl function. Given a URL and an MD5 hash of the expected contents of the file @@ -246,7 +245,7 @@ steps: Since Hello needs Perl, we have to make sure that Perl is in the PATH. The perl environment - variable points to the location of the Perl component (since it + variable points to the location of the Perl package (since it was passed in as an attribute to the derivation), so $perl/bin is the directory containing the Perl interpreter. @@ -276,7 +275,7 @@ steps: GNU Hello is a typical Autoconf-based package, so we first have to run its configure script. In Nix - every component is stored in a separate location in the Nix store, + every package is stored in a separate location in the Nix store, for instance /nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1. Nix computes this path by cryptographically hashing all attributes @@ -338,7 +337,7 @@ rec { function; it is missing some arguments that have to be filled in somewhere. In the Nix Packages collection this is done in the file pkgs/top-level/all-packages.nix, where all -Nix expressions for components are imported and called with the +Nix expressions for packages are imported and called with the appropriate arguments. shows some fragments of all-packages.nix. @@ -352,7 +351,7 @@ some fragments of mutually recursive set of attributes. That is, the attributes can refer to each other. This is precisely what we want since we want to plug the - various components into each other. + various packages into each other. @@ -522,8 +521,8 @@ genericBuild The buildInputs variable tells - setup to use the indicated components as - inputs. This means that if a component provides a + setup to use the indicated packages as + inputs. This means that if a package provides a bin subdirectory, it's added to PATH; if it has a include subdirectory, it's added to GCC's header search path; and so @@ -594,9 +593,9 @@ Laziness means that arguments to functions are evaluated only when they are needed. Functional means that functions are normal values that can be passed around and manipulated in interesting ways. The language is not a full-featured, general -purpose language. It's main job is to describe components, -compositions of components, and the variability within -components. +purpose language. It's main job is to describe packages, +compositions of packages, and the variability within +packages. This section presents the various features of the language. @@ -1191,7 +1190,7 @@ set, the attributes of which specify the inputs of the build. There must be an attribute named name whose value must be a string. This is used - as a symbolic name for the component by nix-env, + as a symbolic name for the package by nix-env, and it is appended to the hash in the output path of the derivation. @@ -1579,7 +1578,7 @@ impureEnvVars = ["http_proxy" "https_proxy" ...]; The standard build environment in the Nix Packages collection provides a basic environment for building Unix packages. It consists -of the following components: +of the following packages: @@ -1645,13 +1644,13 @@ following: - All input components specified in the + All input packages specified in the buildInputs environment variable have their /bin subdirectory added to PATH, their /include subdirectory added to the C/C++ header file search path, and their /lib subdirectory added to the linker search path. This can be extended. - For instance, when the pkgconfig component is + For instance, when the pkgconfig package is used, the subdirectory /lib/pkgconfig of each input is added to the PKG_CONFIG_PATH environment variable. @@ -1668,8 +1667,8 @@ following: The setup script also exports a function called genericBuild that knows how to build -typical Autoconf-style components. It can be customised to perform -builds for any type of component. It is advisable to use +typical Autoconf-style packages. It can be customised to perform +builds for any type of package. It is advisable to use genericBuild since it provides facilities that are almost always useful such as unpacking of sources, patching of sources, nested logging, etc.