* component -> package.

8 files changed, 97 insertions, 98 deletions

diff --git a/doc/manual/build-farm.xml b/doc/manual/build-farm.xml
index cfca63f360..9a63458960 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.</para></listitem>
 
   <listitem><para>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.</para></listitem>
 
   <listitem><para>The results of a Nix build farm can be made
diff --git a/doc/manual/glossary.xml b/doc/manual/glossary.xml
index e76f99a261..efbf96f0af 100644
--- a/doc/manual/glossary.xml
+++ b/doc/manual/glossary.xml
@@ -74,9 +74,9 @@
 
 <glossentry><glossterm>Nix expression</glossterm>
 
-  <glossdef><para>A high-level description of software components and
+  <glossdef><para>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.</para></glossdef>
 
diff --git a/doc/manual/installation.xml b/doc/manual/installation.xml
index 72e4b541a0..d61c0c2307 100644
--- a/doc/manual/installation.xml
+++ b/doc/manual/installation.xml
@@ -42,9 +42,8 @@ platforms as well.</para>
 <section><title>Obtaining Nix</title>
 
 <para>The easiest way to obtain Nix is to download a <link
-xlink:href="http://www.cs.uu.nl/groups/ST/Trace/Nix">source
-distribution</link>.  RPMs for Red Hat, SuSE, and Fedora Core are also
-available.</para>
+xlink:href="http://nix.cs.uu.nl/">source distribution</link>.  RPMs
+for Red Hat, SuSE, and Fedora Core are also available.</para>
 
 <para>Alternatively, the most recent sources of Nix can be obtained
 from its <link
@@ -161,12 +160,12 @@ options.</para>
 
 <section><title>Installing from RPMs</title>
 
-<para>RPM packages of Nix can be downloaded from <uri
-xlink:href="http://www.cs.uu.nl/groups/ST/Trace/Nix">http://www.cs.uu.nl/groups/ST/Trace/Nix</uri>.
-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 <literal>glibc</literal> 2.3 or later.</para>
+<para>RPM packages of Nix can be downloaded from <link
+xlink:href="http://nix.cs.uu.nl/" />.  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
+<literal>glibc</literal> 2.3 or later.</para>
 
 <para>Once downloaded, the RPMs can be installed or upgraded using
 <command>rpm -U</command>.  For example,
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml
index 7f7cd11d5a..d2f23bf44a 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 <emphasis>your</emphasis>
+package will build and work correctly on <emphasis>your</emphasis>
 machine if you have the dependency installed, but not on the end
 user's machine if it's not there.</para>
 
diff --git a/doc/manual/nix-env.xml b/doc/manual/nix-env.xml
index 9af8c0c022..a0ec489fd9 100644
--- a/doc/manual/nix-env.xml
+++ b/doc/manual/nix-env.xml
@@ -48,7 +48,7 @@
 <refsection><title>Description</title>
 
 <para>The command <command>nix-env</command> 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. -->
     <listitem><para>Compare installed versions to available versions,
     or vice versa (if <option>--available</option> 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:
 
     <variablelist>
 
       <varlistentry><term><literal>&lt;</literal> <replaceable>version</replaceable></term>
 
-        <listitem><para>A newer version of the component is available
+        <listitem><para>A newer version of the package is available
         or installed.</para></listitem>
 
       </varlistentry>
       
       <varlistentry><term><literal>=</literal> <replaceable>version</replaceable></term>
 
-        <listitem><para>At most the same version of the component is
+        <listitem><para>At most the same version of the package is
         available or installed.</para></listitem>
 
       </varlistentry>
       
       <varlistentry><term><literal>></literal> <replaceable>version</replaceable></term>
 
-        <listitem><para>Only older versions of the component are
+        <listitem><para>Only older versions of the package are
         available or installed.</para></listitem>
 
       </varlistentry>
       
       <varlistentry><term><literal>- ?</literal></term>
 
-        <listitem><para>No version of the component is available or
+        <listitem><para>No version of the package is available or
         installed.</para></listitem>
 
       </varlistentry>
diff --git a/doc/manual/package-management.xml b/doc/manual/package-management.xml
index a24ca0a696..9ab181692d 100644
--- a/doc/manual/package-management.xml
+++ b/doc/manual/package-management.xml
@@ -6,9 +6,9 @@
 
 
 <para>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 <emphasis>create</emphasis> components should consult
+who want to <emphasis>create</emphasis> packages should consult
 <xref linkend='chap-writing-nix-expressions' />.</para>
 
 
@@ -16,8 +16,8 @@ who want to <emphasis>create</emphasis> components should consult
 
 <para>The main command for package management is <link
 linkend="sec-nix-env"><command>nix-env</command></link>.  You can use
-it to install, upgrade, and erase components, and to query what
-components are installed or are available for installation.</para>
+it to install, upgrade, and erase packages, and to query what
+packages are installed or are available for installation.</para>
 
 <para>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</emphasis>, which is just a directory tree consisting of
 symlinks to the files of the active applications.  </para>
 
 <para>Components are installed from a set of <emphasis>Nix
-expressions</emphasis> that tell Nix how to build those components,
+expressions</emphasis> 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 <link
 xlink:href='http://nix.cs.uu.nl/dist/nix' />.</para>
 
 <para>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:
 
 <screen>
 $ nix-env -qaf nixpkgs-<replaceable>version</replaceable> '*'
@@ -74,7 +74,7 @@ gcc-4.1.1</screen>
 </para>
 
 <para>It is also possible to see the <emphasis>status</emphasis> 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:
 
 <screen>
@@ -86,24 +86,24 @@ IPS bison-1.875d
 ...</screen>
 
 The first character (<literal>I</literal>) indicates whether the
-component is installed in your current user environment.  The second
+package is installed in your current user environment.  The second
 (<literal>P</literal>) 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 (<literal>S</literal>) indicates
 whether there is a so-called <emphasis>substitute</emphasis> 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.</para>
 
 <para>So now that we have a set of Nix expressions we can build the
-components contained in them.  This is done using <literal>nix-env
+packages contained in them.  This is done using <literal>nix-env
 -i</literal>.  For instance,
 
 <screen>
 $ nix-env -f nixpkgs-<replaceable>version</replaceable> -i subversion</screen>
 
-will install the component called <literal>subversion</literal> (which
+will install the package called <literal>subversion</literal> (which
 is, of course, the <link
 xlink:href='http://subversion.tigris.org/'>Subversion version
 management system</link>).</para>
@@ -112,7 +112,7 @@ management system</link>).</para>
 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
 <command>nix-pull</command> command, which must be supplied with a URL
 containing a <emphasis>manifest</emphasis> describing what binaries
@@ -153,7 +153,7 @@ expressions, use <parameter>-i</parameter> instead of
 <parameter>-u</parameter>; <parameter>-i</parameter> will remove
 whatever version is already installed.</para>
 
-<para>You can also upgrade all components for which there are newer
+<para>You can also upgrade all packages for which there are newer
 versions:
 
 <screen>
@@ -199,19 +199,19 @@ set.</para></footnote></para>
 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
 <emphasis>Nix store</emphasis> (typically,
 <filename>/nix/store</filename>).  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
 <filename>/nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3/</filename>,
 while another version might be stored in
 <filename>/nix/store/5mq2jcn36ldlmh93yj1n8s9c95pj7c5s-subversion-1.1.2</filename>.
 The long strings prefixed to the directory names are cryptographic
 hashes<footnote><para>160-bit truncations of SHA-256 hashes encoded in
 a base-32 notation, to be precise.</para></footnote> of
-<emphasis>all</emphasis> inputs involved in building the component —
+<emphasis>all</emphasis> 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.  <xref
 linkend='fig-user-environments' /> shows a part of a typical Nix
 store.</para>
@@ -231,12 +231,12 @@ $ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn</screen>
 
 every time you want to run Subversion.  Of course we could set up the
 <envar>PATH</envar> environment variable to include the
-<filename>bin</filename> directory of every component we want to use,
+<filename>bin</filename> directory of every package we want to use,
 but this is not very convenient since changing <envar>PATH</envar>
 doesn’t take effect for already existing processes.  The solution Nix
 uses is to create directory trees of symlinks to
-<emphasis>activated</emphasis> components.  These are called
-<emphasis>user environments</emphasis> and they are components
+<emphasis>activated</emphasis> packages.  These are called
+<emphasis>user environments</emphasis> and they are packages
 themselves (though automatically generated by
 <command>nix-env</command>), so they too reside in the Nix store.  For
 instance, in <xref linkend='fig-user-environments' /> the user
@@ -285,8 +285,8 @@ operation, a new user environment and generation link are created
 based on the current one, and finally the <filename>default</filename>
 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.)</para>
 
 <para>If you find that you want to undo a <command>nix-env</command>
@@ -352,18 +352,18 @@ This will <emphasis>not</emphasis> change the
 
 <para><command>nix-env</command> operations such as upgrades
 (<option>-u</option>) and uninstall (<option>-e</option>) 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.</para>
+symlinks to the “deleted” packages.</para>
 
-<para>Of course, since disk space is not infinite, unused components
+<para>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.</para>
 
 <para>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
 <screen>
 $ nix-env -u '*'</screen>
 
-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.</para>
 
 </section>
diff --git a/doc/manual/quick-start.xml b/doc/manual/quick-start.xml
index c4065ace19..b51f2b1675 100644
--- a/doc/manual/quick-start.xml
+++ b/doc/manual/quick-start.xml
@@ -11,7 +11,7 @@ to the following chapters.</para>
 <orderedlist>
 
 <listitem><para>Download a source tarball or RPM from <link
-xlink:href='http://www.cs.uu.nl/groups/ST/Trace/Nix'/>.  Build source
+xlink:href='http://nix.cs.uu.nl/'/>.  Build source
 distributions using the regular sequence:
         
 <screen>
@@ -22,8 +22,9 @@ $ make install <lineannotation>(as root)</lineannotation></screen>
 
 This will install Nix in <filename>/nix</filename>.  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
 <filename>/nix/etc/profile.d/nix.sh</filename> to your
 <filename>~/.bashrc</filename> (or some other login
 file).</para></listitem>
@@ -40,14 +41,14 @@ $ nix-channel --add \
 <screen>
 $ nix-channel --update</screen>
 
-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 <filename>~/.nix-defexpr</filename>, in case you're
 curious).  Also, it registers the fact that pre-built binaries are
 available remotely.</para></listitem>
 
-<listitem><para>See what installable components are currently
-available in the channel:
+<listitem><para>See what installable packages are currently available
+in the channel:
 
 <screen>
 $ nix-env -qa ’*’ <lineannotation>(mind the quotes!)</lineannotation>
@@ -59,13 +60,13 @@ libxslt-1.1.0
 
 </para></listitem>
 
-<listitem><para>Install some components from the channel:
+<listitem><para>Install some packages from the channel:
         
 <screen>
 $ nix-env -i hello firefox <replaceable>...</replaceable> </screen>
 
-This should download the pre-built components; it should not build
-them locally (if it does, something went wrong).</para></listitem>
+This should download pre-built packages; it should not build them
+locally (if it does, something went wrong).</para></listitem>
 
 <listitem><para>Test that they work:
 
@@ -92,8 +93,8 @@ $ nix-env -e hello</screen>
 $ nix-channel --update
 $ nix-env -u '*'</screen>
 
-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).</para></listitem>
 
 <listitem><para>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.</para></listitem>
 
 <listitem><para>If you're unhappy with the result of a
-<command>nix-env</command> action (e.g., an upgraded component turned
+<command>nix-env</command> action (e.g., an upgraded package turned
 out not to work properly), you can go back:
 
 <screen>
@@ -124,7 +125,7 @@ $ nix-collect-garbage -d</screen>
 
 <!--
 The first command deletes old “generations” of your profile (making
-rollbacks impossible, but also making the components in those old
+rollbacks impossible, but also making the packages in those old
 generations available for garbage collection), while the second
 command actually deletes them.-->
 
diff --git a/doc/manual/writing-nix-expressions.xml b/doc/manual/writing-nix-expressions.xml
index 5fa9e423d5..54108e9cf0 100644
--- a/doc/manual/writing-nix-expressions.xml
+++ b/doc/manual/writing-nix-expressions.xml
@@ -7,7 +7,7 @@
 
 
 <para>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.</para>
 
@@ -19,29 +19,28 @@ xlink:href='http://www.gnu.org/software/hello/hello.html'>GNU Hello
 package</link> to the Nix Packages collection.  Hello is a program
 that prints out the text <quote>Hello, world!</quote>.</para>
 
-<para>To add a component to the Nix Packages collection, you generally
+<para>To add a package to the Nix Packages collection, you generally
 need to do three things:
 
 <orderedlist>
 
-  <listitem><para>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.</para></listitem>
+  <listitem><para>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.</para></listitem>
 
   <listitem><para>Write a <emphasis>builder</emphasis>.  This is a
   shell script<footnote><para>In fact, it can be written in any
   language, but typically it's a <command>bash</command> shell
-  script.</para></footnote> that actually builds the component from
+  script.</para></footnote> that actually builds the package from
   the inputs.</para></listitem>
 
-  <listitem><para>Add the component to the file
+  <listitem><para>Add the package to the file
   <filename>pkgs/top-level/all-packages.nix</filename>.  The Nix
   expression written in the first step is a
-  <emphasis>function</emphasis>; it requires other components in order
+  <emphasis>function</emphasis>; 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.</para></listitem>
+  package.</para></listitem>
 
 </orderedlist>
 
@@ -83,8 +82,8 @@ the single Nix expression in that directory
     arguments: <varname>stdenv</varname>, <varname>fetchurl</varname>,
     and <varname>perl</varname>.  They are needed to build Hello, but
     we don't know how to build them here; that's why they are function
-    arguments.  <varname>stdenv</varname> is a component that is used
-    by almost all Nix Packages components; it provides a
+    arguments.  <varname>stdenv</varname> is a package that is used
+    by almost all Nix Packages packages; it provides a
     <quote>standard</quote> 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
     <replaceable>e</replaceable> 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.</para>
+    describe how to build an instance of the Hello package.</para>
     
   </callout>
 
   <callout arearefs='ex-hello-nix-co-2'>
 
-    <para>So we have to build a component.  Building something from
+    <para>So we have to build a package.  Building something from
     other stuff is called a <emphasis>derivation</emphasis> in Nix (as
     opposed to sources, which are built by humans instead of
     computers).  We perform a derivation by calling
     <varname>stdenv.mkDerivation</varname>.
     <varname>mkDerivation</varname> is a function provided by
-    <varname>stdenv</varname> that builds a component from a set of
+    <varname>stdenv</varname> that builds a package from a set of
     <emphasis>attributes</emphasis>.  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
   <callout arearefs='ex-hello-nix-co-3'>
 
     <para>The attribute <varname>name</varname> 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 <command>nix-env
     -q</command> to show a <quote>human-readable</quote> name for
-    components.  This attribute is required by
+    packages.  This attribute is required by
     <varname>mkDerivation</varname>.</para>
 
   </callout>
@@ -149,7 +148,7 @@ the single Nix expression in that directory
 
   <callout arearefs='ex-hello-nix-co-5'>
 
-    <para>The builder has to know what the sources of the component
+    <para>The builder has to know what the sources of the package
     are.  Here, the attribute <varname>src</varname> is bound to the
     result of a call to the <command>fetchurl</command> function.
     Given a URL and an MD5 hash of the expected contents of the file
@@ -246,7 +245,7 @@ steps:</para>
 
     <para>Since Hello needs Perl, we have to make sure that Perl is in
     the <envar>PATH</envar>.  The <envar>perl</envar> 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
     <filename><replaceable>$perl</replaceable>/bin</filename> is the
     directory containing the Perl interpreter.</para>
@@ -276,7 +275,7 @@ steps:</para>
 
     <para>GNU Hello is a typical Autoconf-based package, so we first
     have to run its <filename>configure</filename> 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
     <filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
     Nix computes this path by cryptographically hashing all attributes
@@ -338,7 +337,7 @@ rec { <co xml:id='ex-hello-composition-co-1' />
 function; it is missing some arguments that have to be filled in
 somewhere.  In the Nix Packages collection this is done in the file
 <filename>pkgs/top-level/all-packages.nix</filename>, where all
-Nix expressions for components are imported and called with the
+Nix expressions for packages are imported and called with the
 appropriate arguments.  <xref linkend='ex-hello-composition' /> shows
 some fragments of
 <filename>all-packages.nix</filename>.</para>
@@ -352,7 +351,7 @@ some fragments of
     <emphasis>mutually recursive</emphasis> set of attributes.  That
     is, the attributes can refer to each other.  This is precisely
     what we want since we want to <quote>plug</quote> the
-    various components into each other.</para>
+    various packages into each other.</para>
 
   </callout>
 
@@ -522,8 +521,8 @@ genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
   <callout arearefs='ex-hello-builder2-co-1'>
     
     <para>The <envar>buildInputs</envar> variable tells
-    <filename>setup</filename> to use the indicated components as
-    <quote>inputs</quote>.  This means that if a component provides a
+    <filename>setup</filename> to use the indicated packages as
+    <quote>inputs</quote>.  This means that if a package provides a
     <filename>bin</filename> subdirectory, it's added to
     <envar>PATH</envar>; if it has a <filename>include</filename>
     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
 <quote>normal</quote> 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.</para>
+purpose language.  It's main job is to describe packages,
+compositions of packages, and the variability within
+packages.</para>
 
 <para>This section presents the various features of the
 language.</para>
@@ -1191,7 +1190,7 @@ set, the attributes of which specify the inputs of the build.</para>
 
   <listitem><para>There must be an attribute named
   <varname>name</varname> whose value must be a string.  This is used
-  as a symbolic name for the component by <command>nix-env</command>,
+  as a symbolic name for the package by <command>nix-env</command>,
   and it is appended to the hash in the output path of the
   derivation.</para></listitem>
 
@@ -1579,7 +1578,7 @@ impureEnvVars = ["http_proxy" "https_proxy" <replaceable>...</replaceable>];
 
 <para>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:
 
 <itemizedlist>
 
@@ -1645,13 +1644,13 @@ following:
 
 <itemizedlist>
 
-  <listitem><para>All input components specified in the
+  <listitem><para>All input packages specified in the
   <envar>buildInputs</envar> environment variable have their
   <filename>/bin</filename> subdirectory added to <envar>PATH</envar>,
   their <filename>/include</filename> subdirectory added to the C/C++
   header file search path, and their <filename>/lib</filename>
   subdirectory added to the linker search path.  This can be extended.
-  For instance, when the <command>pkgconfig</command> component is
+  For instance, when the <command>pkgconfig</command> package is
   used, the subdirectory <filename>/lib/pkgconfig</filename> of each
   input is added to the <envar>PKG_CONFIG_PATH</envar> environment
   variable.</para></listitem>
@@ -1668,8 +1667,8 @@ following:
 
 <para>The <filename>setup</filename> script also exports a function
 called <function>genericBuild</function> 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
 <function>genericBuild</function> since it provides facilities that
 are almost always useful such as unpacking of sources, patching of
 sources, nested logging, etc.</para>