forked from lix-project/lix
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 Nix 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 Nix Package collection; you could write your own Nix
|
||
expressions based on it, 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>
|