184 lines
4.8 KiB
XML
184 lines
4.8 KiB
XML
<chapter>
|
|
<title>Introduction</title>
|
|
|
|
<sect1>
|
|
<title>The problem space</title>
|
|
|
|
<para>
|
|
Nix is a system for controlling the automatic creation and distribution
|
|
of data, such as computer programs and other software artifacts. This is
|
|
a very general problem, and there are many applications that fall under
|
|
this description.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Build management</title>
|
|
|
|
<para>
|
|
Build management tools are used to perform <emphasis>software
|
|
builds</emphasis>, that is, the construction of derived products such
|
|
as executable programs from source code. A commonly used build tool is
|
|
Make, which is a standard tool on Unix systems. These tools have to
|
|
deal with several issues:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Package management</title>
|
|
|
|
<para>
|
|
After software has been built, is must also be
|
|
<emphasis>deployed</emphasis> in the intended target environment, e.g.,
|
|
the user's workstation. Examples include the Red Hat package manager
|
|
(RPM), Microsoft's MSI, and so on. Here also we have to deal with
|
|
several issues:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The <emphasis>creation</emphasis> of packages from some formal
|
|
description of what artifacts should be distributed in the
|
|
package.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The <emphasis>deployment</emphasis> of packages, that is, the
|
|
mechanism by which we get them onto the intended target
|
|
environment. This can be as simple as copying a file, but
|
|
complexity comes from the wide range of possible installation
|
|
media (such as a network install), and the scalability of the
|
|
process (if a program must be installed on a thousand systems, we
|
|
do not want to visit each system and perform some manual steps to
|
|
install the program on that system; that is, the complexity for
|
|
the system administrator should be constant, not linear).
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
|
|
<!--######################################################################-->
|
|
|
|
<sect1>
|
|
<title>What Nix can do for you</title>
|
|
|
|
<para>
|
|
Here is a summary of what Nix provides:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Reliable dependencies.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Support for variability.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Transparent source/binary deployment.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Easy configuration duplication.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Automatic storage management.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Atomic upgrades and rollbacks.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Support for many simultaneous configurations.</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Here is what Nix doesn't yet provide, but will:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Build management.</emphasis> In principle it is already
|
|
possible to do build management using Fix (by writing builders that
|
|
perform appropriate build steps), but the Fix language is not yet
|
|
powerful enough to make this pleasant. The <ulink
|
|
url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>
|
|
should be retargeted to produce Nix expressions, or alternatively,
|
|
extend Fix with Maak's semantics and concrete syntax (since Fix needs
|
|
a concrete syntax anyway). Another interesting idea is to write a
|
|
<command>make</command> implementation that uses Nix as a back-end to
|
|
support <ulink
|
|
url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
|
|
build files.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</sect1>
|
|
|
|
|
|
<!--######################################################################-->
|
|
|
|
<sect1>
|
|
<title>The Nix system</title>
|
|
|
|
<para>
|
|
...
|
|
</para>
|
|
|
|
<para>
|
|
Existing tools in this field generally both a underlying model (such as
|
|
the derivation graph of build tools, or the versioning scheme that
|
|
determines when two packages are <quote>compatible</quote> in a package
|
|
management system) and a formalism that allows ...
|
|
</para>
|
|
|
|
<para>
|
|
Following the principle of separation of mechanism and policy, the Nix
|
|
system separates the <emphasis>low-level aspect</emphasis> of file system
|
|
object management form the <emphasis>high-level aspect</emphasis> of the
|
|
...
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|
|
<!--
|
|
local variables:
|
|
sgml-parent-document: ("book.xml" "chapter")
|
|
end:
|
|
-->
|