about summary refs log tree commit diff
path: root/third_party/nix/doc/manual/packages/basic-package-mgmt.xml
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/nix/doc/manual/packages/basic-package-mgmt.xml')
-rw-r--r--third_party/nix/doc/manual/packages/basic-package-mgmt.xml194
1 files changed, 0 insertions, 194 deletions
diff --git a/third_party/nix/doc/manual/packages/basic-package-mgmt.xml b/third_party/nix/doc/manual/packages/basic-package-mgmt.xml
deleted file mode 100644
index 0f21297f31b9..000000000000
--- a/third_party/nix/doc/manual/packages/basic-package-mgmt.xml
+++ /dev/null
@@ -1,194 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-      xmlns:xlink="http://www.w3.org/1999/xlink"
-      xmlns:xi="http://www.w3.org/2001/XInclude"
-      version="5.0"
-      xml:id="ch-basic-package-mgmt">
-
-<title>Basic Package Management</title>
-
-<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 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
-applications present on the system (possibly in many different
-versions), but users can have a specific selection of those active —
-where “active” just means that it appears in a directory
-in the user’s <envar>PATH</envar>.  Such a view on the set of
-installed applications is called a <emphasis>user
-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 packages,
-including, if necessary, their dependencies.  There is a collection of
-Nix expressions called the Nixpkgs package collection that contains
-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 Nixpkgs package collection; you could write your own Nix
-expressions based on Nixpkgs, or completely new ones.)</para>
-
-<para>You can manually download the latest version of Nixpkgs from
-<link xlink:href='http://nixos.org/nixpkgs/download.html'/>. However,
-it’s much more convenient to use the Nixpkgs
-<emphasis>channel</emphasis>, since it makes it easy to stay up to
-date with new versions of Nixpkgs. (Channels are described in more
-detail in <xref linkend="sec-channels"/>.) Nixpkgs is automatically
-added to your list of “subscribed” channels when you install
-Nix. If this is not the case for some reason, you can add it as
-follows:
-
-<screen>
-$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
-$ nix-channel --update
-</screen>
-
-</para>
-
-<note><para>On NixOS, you’re automatically subscribed to a NixOS
-channel corresponding to your NixOS major release
-(e.g. <uri>http://nixos.org/channels/nixos-14.12</uri>). A NixOS
-channel is identical to the Nixpkgs channel, except that it contains
-only Linux binaries and is updated only if a set of regression tests
-succeed.</para></note>
-
-<para>You can view the set of available packages in Nixpkgs:
-
-<screen>
-$ nix-env -qa
-aterm-2.2
-bash-3.0
-binutils-2.15
-bison-1.875d
-blackdown-1.4.2
-bzip2-1.0.2
-…</screen>
-
-The flag <option>-q</option> specifies a query operation, and
-<option>-a</option> means that you want to show the “available” (i.e.,
-installable) packages, as opposed to the installed packages. If you
-downloaded Nixpkgs yourself, or if you checked it out from GitHub,
-then you need to pass the path to your Nixpkgs tree using the
-<option>-f</option> flag:
-
-<screen>
-$ nix-env -qaf <replaceable>/path/to/nixpkgs</replaceable>
-</screen>
-
-where <replaceable>/path/to/nixpkgs</replaceable> is where you’ve
-unpacked or checked out Nixpkgs.</para>
-
-<para>You can select specific packages by name:
-
-<screen>
-$ nix-env -qa firefox
-firefox-34.0.5
-firefox-with-plugins-34.0.5
-</screen>
-
-and using regular expressions:
-
-<screen>
-$ nix-env -qa 'firefox.*'
-</screen>
-
-</para>
-
-<para>It is also possible to see the <emphasis>status</emphasis> of
-available packages, i.e., whether they are installed into the user
-environment and/or present in the system:
-
-<screen>
-$ nix-env -qas
-…
--PS bash-3.0
---S binutils-2.15
-IPS bison-1.875d
-…</screen>
-
-The first character (<literal>I</literal>) indicates whether the
-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
-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>You can install a package using <literal>nix-env -i</literal>.
-For instance,
-
-<screen>
-$ nix-env -i subversion</screen>
-
-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>
-
-<note><para>When you ask Nix to install a package, it will first try
-to get it in pre-compiled form from a <emphasis>binary
-cache</emphasis>. By default, Nix will use the binary cache
-<uri>https://cache.nixos.org</uri>; it contains binaries for most
-packages in Nixpkgs. Only if no binary is available in the binary
-cache, Nix will build the package from source. So if <literal>nix-env
--i subversion</literal> results in Nix building stuff from source,
-then either the package is not built for your platform by the Nixpkgs
-build servers, or your version of Nixpkgs is too old or too new. For
-instance, if you have a very recent checkout of Nixpkgs, then the
-Nixpkgs build servers may not have had a chance to build everything
-and upload the resulting binaries to
-<uri>https://cache.nixos.org</uri>. The Nixpkgs channel is only
-updated after all binaries have been uploaded to the cache, so if you
-stick to the Nixpkgs channel (rather than using a Git checkout of the
-Nixpkgs tree), you will get binaries for most packages.</para></note>
-
-<para>Naturally, packages can also be uninstalled:
-
-<screen>
-$ nix-env -e subversion</screen>
-
-</para>
-
-<para>Upgrading to a new version is just as easy.  If you have a new
-release of Nix Packages, you can do:
-
-<screen>
-$ nix-env -u subversion</screen>
-
-This will <emphasis>only</emphasis> upgrade Subversion if there is a
-“newer” version in the new set of Nix expressions, as
-defined by some pretty arbitrary rules regarding ordering of version
-numbers (which generally do what you’d expect of them).  To just
-unconditionally replace Subversion with whatever version is in the Nix
-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 packages for which there are newer
-versions:
-
-<screen>
-$ nix-env -u</screen>
-
-</para>
-
-<para>Sometimes it’s useful to be able to ask what
-<command>nix-env</command> would do, without actually doing it.  For
-instance, to find out what packages would be upgraded by
-<literal>nix-env -u</literal>, you can do
-
-<screen>
-$ nix-env -u --dry-run
-(dry run; not doing anything)
-upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
-upgrading `graphviz-1.10' to `graphviz-1.12'
-upgrading `coreutils-5.0' to `coreutils-5.2.1'</screen>
-
-</para>
-
-</chapter>