diff options
author | Eelco Dolstra <e.dolstra@tudelft.nl> | 2003-08-13T15·17+0000 |
---|---|---|
committer | Eelco Dolstra <e.dolstra@tudelft.nl> | 2003-08-13T15·17+0000 |
commit | 95b49f804456cf532e61478d7f604aed381173d7 (patch) | |
tree | bcb4a97c21ea8469329e24c3435f108e152890a3 /doc/manual/introduction.xml | |
parent | 68022552d295e5a223b87a1a96814fd2586350ed (diff) |
* Manual updates.
Diffstat (limited to 'doc/manual/introduction.xml')
-rw-r--r-- | doc/manual/introduction.xml | 98 |
1 files changed, 92 insertions, 6 deletions
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml index 77a5f917ee71..974cdedd8fae 100644 --- a/doc/manual/introduction.xml +++ b/doc/manual/introduction.xml @@ -15,17 +15,17 @@ <title>Build management</title> <para> - Build management tools are used to perform <emphasis>software + 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> + <itemizedlist> <listitem> <para> </para> </listitem> - </itemizedlist> + </itemizedlist> </para> </sect2> @@ -34,12 +34,12 @@ <title>Package management</title> <para> - After software has been built, is must also be + 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> + <itemizedlist> <listitem> <para> The <emphasis>creation</emphasis> of packages from some formal @@ -60,12 +60,98 @@ the system administrator should be constant, not linear). </para> </listitem> - </itemizedlist> + </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> |