mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

* component -> package.

Browse source
This commit is contained in:
Eelco Dolstra 2007-12-04 11:42:58 +00:00
parent 6d6c68c0d2
commit d4950f207f
8 changed files with 97 additions and 98 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/manual/build-farm.xml
View file

@ -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

4
doc/manual/glossary.xml
View file

@ -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>

17
doc/manual/installation.xml
View file

@ -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,

2
doc/manual/introduction.xml
View file

@ -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>

12
doc/manual/nix-env.xml
View file

@ -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>

60
doc/manual/package-management.xml
View file

@ -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>

27
doc/manual/quick-start.xml
View file

@ -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.-->

65
doc/manual/writing-nix-expressions.xml
View file

@ -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>