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>
 |