forked from lix-project/lix
288f93cec0
Makes difference between Nix and Nixpkgs clearer to avoid some common confusion this sentence on IRC. Also disambiguate an "it" reference.
194 lines
6.9 KiB
XML
194 lines
6.9 KiB
XML
<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>
|