* component -> package.

1 files changed, 32 insertions, 33 deletions

diff --git a/doc/manual/writing-nix-expressions.xml b/doc/manual/writing-nix-expressions.xml
index 5fa9e423d51b..54108e9cf0ba 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>