2014-08-27 19:41:09 +03:00
|
|
|
|
<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
|
2019-04-14 04:18:33 +03:00
|
|
|
|
Nix expressions called the Nixpkgs package collection that contains
|
2014-08-27 19:41:09 +03:00
|
|
|
|
packages ranging from basic development stuff such as GCC and Glibc,
|
|
|
|
|
to end-user applications like Mozilla Firefox. (Nix is however not
|
2019-04-14 04:18:33 +03:00
|
|
|
|
tied to the Nixpkgs package collection; you could write your own Nix
|
|
|
|
|
expressions based on Nixpkgs, or completely new ones.)</para>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
|
|
|
|
|
<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
|
2015-01-05 14:27:33 +02:00
|
|
|
|
added to your list of “subscribed” channels when you install
|
2014-12-14 00:16:08 +02:00
|
|
|
|
Nix. If this is not the case for some reason, you can add it as
|
|
|
|
|
follows:
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
2014-12-14 00:16:08 +02:00
|
|
|
|
<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:
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
<screen>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -qa
|
2014-08-27 19:41:09 +03:00
|
|
|
|
aterm-2.2
|
|
|
|
|
bash-3.0
|
|
|
|
|
binutils-2.15
|
|
|
|
|
bison-1.875d
|
|
|
|
|
blackdown-1.4.2
|
|
|
|
|
bzip2-1.0.2
|
2014-12-14 00:16:08 +02:00
|
|
|
|
…</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:
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
<screen>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -qa 'firefox.*'
|
|
|
|
|
</screen>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
</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>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -qas
|
|
|
|
|
…
|
2014-08-27 19:41:09 +03:00
|
|
|
|
-PS bash-3.0
|
|
|
|
|
--S binutils-2.15
|
|
|
|
|
IPS bison-1.875d
|
2014-12-14 00:16:08 +02:00
|
|
|
|
…</screen>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
2014-12-14 00:16:08 +02:00
|
|
|
|
<para>You can install a package using <literal>nix-env -i</literal>.
|
|
|
|
|
For instance,
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
<screen>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -i subversion</screen>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
2014-12-14 00:16:08 +02:00
|
|
|
|
<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>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
<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>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -u subversion</screen>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
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>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -u</screen>
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
</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
|
2014-12-14 00:16:08 +02:00
|
|
|
|
<literal>nix-env -u</literal>, you can do
|
2014-08-27 19:41:09 +03:00
|
|
|
|
|
|
|
|
|
<screen>
|
2014-12-14 00:16:08 +02:00
|
|
|
|
$ nix-env -u --dry-run
|
2014-08-27 19:41:09 +03:00
|
|
|
|
(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>
|
|
|
|
|
|
2014-12-14 00:16:08 +02:00
|
|
|
|
</chapter>
|