guix.texi

Once this is done, you should be able to reboot the system and boot from
the USB stick or DVD.  The latter usually requires you to get in the
BIOS or UEFI boot menu, where you can choose to boot from the USB stick.

@xref{Installing Guix in a VM}, if, instead, you would like to install
Guix System in a virtual machine (VM).


@node Preparing for Installation
@section Preparing for Installation

Once you have booted, you can use the guided graphical installer, which makes
it easy to get started (@pxref{Guided Graphical Installation}).  Alternately,
if you are already familiar with GNU/Linux and if you want more control than
what the graphical installer provides, you can choose the ``manual''
installation process (@pxref{Manual Installation}).

The graphical installer is available on TTY1.  You can obtain root shells on
TTYs 3 to 6 by hitting @kbd{ctrl-alt-f3}, @kbd{ctrl-alt-f4}, etc.  TTY2 shows
this documentation and you can reach it with @kbd{ctrl-alt-f2}.  Documentation
is browsable using the Info reader commands (@pxref{Top,,, info-stnd,
Stand-alone GNU Info}).  The installation system runs the GPM mouse daemon,
which allows you to select text with the left mouse button and to paste it
with the middle button.

@quotation Note
Installation requires access to the Internet so that any missing
dependencies of your system configuration can be downloaded.  See the
``Networking'' section below.
@end quotation

@node Guided Graphical Installation
@section Guided Graphical Installation

The graphical installer is a text-based user interface.  It will guide you,
with dialog boxes, through the steps needed to install GNU@tie{}Guix System.

The first dialog boxes allow you to set up the system as you use it during the
installation: you can choose the language, keyboard layout, and set up
networking, which will be used during the installation.  The image below shows
the networking dialog.

@image{images/installer-network,5in,, networking setup with the graphical installer}

Later steps allow you to partition your hard disk, as shown in the image
below, to choose whether or not to use encrypted file systems, to enter the
host name and root password, and to create an additional account, among other
things.

@image{images/installer-partitions,5in,, partitioning with the graphical installer}

Note that, at any time, the installer allows you to exit the current
installation step and resume at a previous step, as show in the image below.

@image{images/installer-resume,5in,, resuming the installation process}

Once you're done, the installer produces an operating system configuration and
displays it (@pxref{Using the Configuration System}).  At that point you can
hit ``OK'' and installation will proceed.  On success, you can reboot into the
new system and enjoy.  @xref{After System Installation}, for what's next!


@node Manual Installation
@section Manual Installation

This section describes how you would ``manually'' install GNU@tie{}Guix System
on your machine.  This option requires familiarity with GNU/Linux, with the
shell, and with common administration tools.  If you think this is not for
you, consider using the guided graphical installer (@pxref{Guided Graphical
Installation}).

The installation system provides root shells on TTYs 3 to 6; press
@kbd{ctrl-alt-f3}, @kbd{ctrl-alt-f4}, and so on to reach them.  It includes
many common tools needed to install the system.  But it is also a full-blown
Guix System, which means that you can install additional packages, should you
need it, using @command{guix package} (@pxref{Invoking guix package}).

@menu
* Keyboard Layout and Networking and Partitioning:: Initial setup.
* Proceeding with the Installation::  Installing.
@end menu

@node Keyboard Layout and Networking and Partitioning
@subsection Keyboard Layout, Networking, and Partitioning

Before you can install the system, you may want to adjust the keyboard layout,
set up networking, and partition your target hard disk.  This section will
guide you through this.

@subsubsection Keyboard Layout

@cindex keyboard layout
The installation image uses the US qwerty keyboard layout.  If you want
to change it, you can use the @command{loadkeys} command.  For example,
the following command selects the Dvorak keyboard layout:

@example
loadkeys dvorak
@end example

See the files under @file{/run/current-system/profile/share/keymaps} for
a list of available keyboard layouts.  Run @command{man loadkeys} for
more information.

@subsubsection Networking

Run the following command to see what your network interfaces are called:

@example
ifconfig -a
@end example

@noindent
@dots{} or, using the GNU/Linux-specific @command{ip} command:

@example
ip address
@end example

@c https://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
Wired interfaces have a name starting with @samp{e}; for example, the
interface corresponding to the first on-board Ethernet controller is
called @samp{eno1}.  Wireless interfaces have a name starting with
@samp{w}, like @samp{w1p2s0}.

@table @asis
@item Wired connection
To configure a wired network run the following command, substituting
@var{interface} with the name of the wired interface you want to use.

@example
ifconfig @var{interface} up
@end example

@noindent
@dots{} or, using the GNU/Linux-specific @command{ip} command:

@example
ip link set @var{interface} up
@end example

@item Wireless connection
@cindex wireless
@cindex WiFi
To configure wireless networking, you can create a configuration file
for the @command{wpa_supplicant} configuration tool (its location is not
important) using one of the available text editors such as
@command{nano}:

@example
nano wpa_supplicant.conf
@end example

As an example, the following stanza can go to this file and will work
for many wireless networks, provided you give the actual SSID and
passphrase for the network you are connecting to:

@example
network=@{
  ssid="@var{my-ssid}"
  key_mgmt=WPA-PSK
  psk="the network's secret passphrase"
@}
@end example

Start the wireless service and run it in the background with the
following command (substitute @var{interface} with the name of the
network interface you want to use):

@example
wpa_supplicant -c wpa_supplicant.conf -i @var{interface} -B
@end example

Run @command{man wpa_supplicant} for more information.
@end table

@cindex DHCP
At this point, you need to acquire an IP address.  On a network where IP
addresses are automatically assigned @i{via} DHCP, you can run:

@example
dhclient -v @var{interface}
@end example

Try to ping a server to see if networking is up and running:

@example
ping -c 3 gnu.org
@end example

Setting up network access is almost always a requirement because the
image does not contain all the software and tools that may be needed.

@cindex installing over SSH
If you want to, you can continue the installation remotely by starting
an SSH server:

@example
herd start ssh-daemon
@end example

Make sure to either set a password with @command{passwd}, or configure
OpenSSH public key authentication before logging in.

@subsubsection Disk Partitioning

Unless this has already been done, the next step is to partition, and
then format the target partition(s).

The installation image includes several partitioning tools, including
Parted (@pxref{Overview,,, parted, GNU Parted User Manual}),
@command{fdisk}, and @command{cfdisk}.  Run it and set up your disk with
the partition layout you want:

@example
cfdisk
@end example

If your disk uses the GUID Partition Table (GPT) format and you plan to
install BIOS-based GRUB (which is the default), make sure a BIOS Boot
Partition is available (@pxref{BIOS installation,,, grub, GNU GRUB
manual}).

@cindex EFI, installation
@cindex UEFI, installation
@cindex ESP, EFI system partition
If you instead wish to use EFI-based GRUB, a FAT32 @dfn{EFI System Partition}
(ESP) is required.  This partition can be mounted at @file{/boot/efi} for
instance and must have the @code{esp} flag set.  E.g., for @command{parted}:

@example
parted /dev/sda set 1 esp on
@end example

@quotation Note
@vindex grub-bootloader
@vindex grub-efi-bootloader
Unsure whether to use EFI- or BIOS-based GRUB?  If the directory
@file{/sys/firmware/efi} exists in the installation image, then you should
probably perform an EFI installation, using @code{grub-efi-bootloader}.
Otherwise you should use the BIOS-based GRUB, known as
@code{grub-bootloader}.  @xref{Bootloader Configuration}, for more info on
bootloaders.
@end quotation

Once you are done partitioning the target hard disk drive, you have to
create a file system on the relevant partition(s)@footnote{Currently
Guix System only supports ext4 and btrfs file systems.  In particular, code
that reads file system UUIDs and labels only works for these file system
types.}.  For the ESP, if you have one and assuming it is
@file{/dev/sda1}, run:

@example
mkfs.fat -F32 /dev/sda1
@end example

Preferably, assign file systems a label so that you can easily and
reliably refer to them in @code{file-system} declarations (@pxref{File
Systems}).  This is typically done using the @code{-L} option of
@command{mkfs.ext4} and related commands.  So, assuming the target root
partition lives at @file{/dev/sda2}, a file system with the label
@code{my-root} can be created with:

@example
mkfs.ext4 -L my-root /dev/sda2
@end example

@cindex encrypted disk
If you are instead planning to encrypt the root partition, you can use
the Cryptsetup/LUKS utilities to do that (see @inlinefmtifelse{html,
@uref{https://linux.die.net/man/8/cryptsetup, @code{man cryptsetup}},
@code{man cryptsetup}} for more information.)  Assuming you want to
store the root partition on @file{/dev/sda2}, the command sequence would
be along these lines:

@example
cryptsetup luksFormat /dev/sda2
cryptsetup open --type luks /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition
@end example

Once that is done, mount the target file system under @file{/mnt}
with a command like (again, assuming @code{my-root} is the label of the
root file system):

@example
mount LABEL=my-root /mnt
@end example

Also mount any other file systems you would like to use on the target
system relative to this path.  If you have opted for @file{/boot/efi} as an
EFI mount point for example, mount it at @file{/mnt/boot/efi} now so it is
found by @code{guix system init} afterwards.

Finally, if you plan to use one or more swap partitions (@pxref{Memory
Concepts, swap space,, libc, The GNU C Library Reference Manual}), make
sure to initialize them with @command{mkswap}.  Assuming you have one
swap partition on @file{/dev/sda3}, you would run:

@example
mkswap /dev/sda3
swapon /dev/sda3
@end example

Alternatively, you may use a swap file.  For example, assuming that in
the new system you want to use the file @file{/swapfile} as a swap file,
you would run@footnote{This example will work for many types of file
systems (e.g., ext4).  However, for copy-on-write file systems (e.g.,
btrfs), the required steps may be different.  For details, see the
manual pages for @command{mkswap} and @command{swapon}.}:

@example
# This is 10 GiB of swap space.  Adjust "count" to change the size.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# For security, make the file readable and writable only by root.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile
@end example

Note that if you have encrypted the root partition and created a swap
file in its file system as described above, then the encryption also
protects the swap file, just like any other file in that file system.

@node Proceeding with the Installation
@subsection Proceeding with the Installation

With the target partitions ready and the target root mounted on
@file{/mnt}, we're ready to go.  First, run:

@example
herd start cow-store /mnt
@end example

This makes @file{/gnu/store} copy-on-write, such that packages added to it
during the installation phase are written to the target disk on @file{/mnt}
rather than kept in memory.  This is necessary because the first phase of
the @command{guix system init} command (see below) entails downloads or
builds to @file{/gnu/store} which, initially, is an in-memory file system.

Next, you have to edit a file and
provide the declaration of the operating system to be installed.  To
that end, the installation system comes with three text editors.  We
recommend GNU nano (@pxref{Top,,, nano, GNU nano Manual}), which
supports syntax highlighting and parentheses matching; other editors
include GNU Zile (an Emacs clone), and
nvi (a clone of the original BSD @command{vi} editor).
We strongly recommend storing that file on the target root file system, say,
as @file{/mnt/etc/config.scm}.  Failing to do that, you will have lost your
configuration file once you have rebooted into the newly-installed system.

@xref{Using the Configuration System}, for an overview of the
configuration file.  The example configurations discussed in that
section are available under @file{/etc/configuration} in the
installation image.  Thus, to get started with a system configuration
providing a graphical display server (a ``desktop'' system), you can run
something along these lines:

@example
# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm
@end example

You should pay attention to what your configuration file contains, and
in particular:

@itemize
@item
Make sure the @code{bootloader-configuration} form refers to the target
you want to install GRUB on.  It should mention @code{grub-bootloader} if
you are installing GRUB in the legacy way, or @code{grub-efi-bootloader}
for newer UEFI systems.  For legacy systems, the @code{target} field
names a device, like @code{/dev/sda}; for UEFI systems it names a path
to a mounted EFI partition, like @code{/boot/efi}; do make sure the path is
currently mounted and a @code{file-system} entry is specified in your
configuration.

@item
Be sure that your file system labels match the value of their respective
@code{device} fields in your @code{file-system} configuration, assuming
your @code{file-system} configuration uses the @code{file-system-label}
procedure in its @code{device} field.

@item
If there are encrypted or RAID partitions, make sure to add a
@code{mapped-devices} field to describe them (@pxref{Mapped Devices}).
@end itemize

Once you are done preparing the configuration file, the new system must
be initialized (remember that the target root file system is mounted
under @file{/mnt}):

@example
guix system init /mnt/etc/config.scm /mnt
@end example

@noindent
This copies all the necessary files and installs GRUB on
@file{/dev/sdX}, unless you pass the @option{--no-bootloader} option.  For
more information, @pxref{Invoking guix system}.  This command may trigger
downloads or builds of missing packages, which can take some time.

Once that command has completed---and hopefully succeeded!---you can run
@command{reboot} and boot into the new system.  The @code{root} password
in the new system is initially empty; other users' passwords need to be
initialized by running the @command{passwd} command as @code{root},
unless your configuration specifies otherwise
(@pxref{user-account-password, user account passwords}).
@xref{After System Installation}, for what's next!


@node After System Installation
@section After System Installation

Success, you've now booted into Guix System!  From then on, you can update the
system whenever you want by running, say:

@example
guix pull
sudo guix system reconfigure /etc/config.scm
@end example

@noindent
This builds a new system generation with the latest packages and services
(@pxref{Invoking guix system}).  We recommend doing that regularly so that
your system includes the latest security updates (@pxref{Security Updates}).

@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
@quotation Note
@cindex sudo vs. @command{guix pull}
Note that @command{sudo guix} runs your user's @command{guix} command and
@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
@end quotation

Join us on @code{#guix} on the Freenode IRC network or on
@email{guix-devel@@gnu.org} to share your experience!


@node Installing Guix in a VM
@section Installing Guix in a Virtual Machine

@cindex virtual machine, Guix System installation
@cindex virtual private server (VPS)
@cindex VPS (virtual private server)
If you'd like to install Guix System in a virtual machine (VM) or on a
virtual private server (VPS) rather than on your beloved machine, this
section is for you.

To boot a @uref{https://qemu.org/,QEMU} VM for installing Guix System in a
disk image, follow these steps:

@enumerate
@item
First, retrieve and decompress the Guix system installation image as
described previously (@pxref{USB Stick and DVD Installation}).

@item
Create a disk image that will hold the installed system.  To make a
qcow2-formatted disk image, use the @command{qemu-img} command:

@example
qemu-img create -f qcow2 guix-system.img 50G
@end example

The resulting file will be much smaller than 50 GB (typically less than
1 MB), but it will grow as the virtualized storage device is filled up.

@item
Boot the USB installation image in an VM:

@example
qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
  -net user -net nic,model=virtio -boot menu=on,order=d \
  -drive file=guix-system.img \
  -drive media=cdrom,file=guix-system-install-@value{VERSION}.@var{system}.iso
@end example

@code{-enable-kvm} is optional, but significantly improves performance,
@pxref{Running Guix in a VM}.

@item
You're now root in the VM, proceed with the installation process.
@xref{Preparing for Installation}, and follow the instructions.
@end enumerate

Once installation is complete, you can boot the system that's on your
@file{guix-system.img} image.  @xref{Running Guix in a VM}, for how to do
that.

@node Building the Installation Image
@section Building the Installation Image

@cindex installation image
The installation image described above was built using the @command{guix
system} command, specifically:

@example
guix system disk-image --file-system-type=iso9660 \
  gnu/system/install.scm
@end example

Have a look at @file{gnu/system/install.scm} in the source tree,
and see also @ref{Invoking guix system} for more information
about the installation image.

@section Building the Installation Image for ARM Boards

Many ARM boards require a specific variant of the
@uref{https://www.denx.de/wiki/U-Boot/, U-Boot} bootloader.

If you build a disk image and the bootloader is not available otherwise
(on another boot drive etc), it's advisable to build an image that
includes the bootloader, specifically:

@example
guix system disk-image --system=armhf-linux -e '((@@ (gnu system install) os-with-u-boot) (@@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'
@end example

@code{A20-OLinuXino-Lime2} is the name of the board.  If you specify an invalid
board, a list of possible boards will be printed.

@c *********************************************************************
@node Package Management
@chapter Package Management

@cindex packages
The purpose of GNU Guix is to allow users to easily install, upgrade, and
remove software packages, without having to know about their build
procedures or dependencies.  Guix also goes beyond this obvious set of
features.

This chapter describes the main features of Guix, as well as the
package management tools it provides.  Along with the command-line
interface described below (@pxref{Invoking guix package, @code{guix
package}}), you may also use the Emacs-Guix interface (@pxref{Top,,,
emacs-guix, The Emacs-Guix Reference Manual}), after installing
@code{emacs-guix} package (run @kbd{M-x guix-help} command to start
with it):

@example
guix install emacs-guix
@end example

@menu
* Features::                    How Guix will make your life brighter.
* Invoking guix package::       Package installation, removal, etc.
* Substitutes::                 Downloading pre-built binaries.
* Packages with Multiple Outputs::  Single source package, multiple outputs.
* Invoking guix gc::            Running the garbage collector.
* Invoking guix pull::          Fetching the latest Guix and distribution.
* Channels::                    Customizing the package collection.
* Invoking guix time-machine::  Running an older revision of Guix.
* Inferiors::                   Interacting with another revision of Guix.
* Invoking guix describe::      Display information about your Guix revision.
* Invoking guix archive::       Exporting and importing store files.
@end menu

@node Features
@section Features

When using Guix, each package ends up in the @dfn{package store}, in its
own directory---something that resembles
@file{/gnu/store/xxx-package-1.2}, where @code{xxx} is a base32 string.

Instead of referring to these directories, users have their own
@dfn{profile}, which points to the packages that they actually want to
use.  These profiles are stored within each user's home directory, at
@code{$HOME/.guix-profile}.

For example, @code{alice} installs GCC 4.7.2.  As a result,
@file{/home/alice/.guix-profile/bin/gcc} points to
@file{/gnu/store/@dots{}-gcc-4.7.2/bin/gcc}.  Now, on the same machine,
@code{bob} had already installed GCC 4.8.0.  The profile of @code{bob}
simply continues to point to
@file{/gnu/store/@dots{}-gcc-4.8.0/bin/gcc}---i.e., both versions of GCC
coexist on the same system without any interference.

The @command{guix package} command is the central tool to manage
packages (@pxref{Invoking guix package}).  It operates on the per-user
profiles, and can be used @emph{with normal user privileges}.

@cindex transactions
The command provides the obvious install, remove, and upgrade
operations.  Each invocation is actually a @emph{transaction}: either
the specified operation succeeds, or nothing happens.  Thus, if the
@command{guix package} process is terminated during the transaction,
or if a power outage occurs during the transaction, then the user's
profile remains in its previous state, and remains usable.

In addition, any package transaction may be @emph{rolled back}.  So, if,
for example, an upgrade installs a new version of a package that turns
out to have a serious bug, users may roll back to the previous instance
of their profile, which was known to work well.  Similarly, the global
system configuration on Guix is subject to
transactional upgrades and roll-back
(@pxref{Using the Configuration System}).

All packages in the package store may be @emph{garbage-collected}.
Guix can determine which packages are still referenced by user
profiles, and remove those that are provably no longer referenced
(@pxref{Invoking guix gc}).  Users may also explicitly remove old
generations of their profile so that the packages they refer to can be
collected.

@cindex reproducibility
@cindex reproducible builds
Guix takes a @dfn{purely functional} approach to package
management, as described in the introduction (@pxref{Introduction}).
Each @file{/gnu/store} package directory name contains a hash of all the
inputs that were used to build that package---compiler, libraries, build
scripts, etc.  This direct correspondence allows users to make sure a
given package installation matches the current state of their
distribution.  It also helps maximize @dfn{build reproducibility}:
thanks to the isolated build environments that are used, a given build
is likely to yield bit-identical files when performed on different
machines (@pxref{Invoking guix-daemon, container}).

@cindex substitutes
This foundation allows Guix to support @dfn{transparent binary/source
deployment}.  When a pre-built binary for a @file{/gnu/store} item is
available from an external source---a @dfn{substitute}, Guix just
downloads it and unpacks it;
otherwise, it builds the package from source, locally
(@pxref{Substitutes}).  Because build results are usually bit-for-bit
reproducible, users do not have to trust servers that provide
substitutes: they can force a local build and @emph{challenge} providers
(@pxref{Invoking guix challenge}).

Control over the build environment is a feature that is also useful for
developers.  The @command{guix environment} command allows developers of
a package to quickly set up the right development environment for their
package, without having to manually install the dependencies of the
package into their profile (@pxref{Invoking guix environment}).

@cindex replication, of software environments
@cindex provenance tracking, of software artifacts
All of Guix and its package definitions is version-controlled, and
@command{guix pull} allows you to ``travel in time'' on the history of Guix
itself (@pxref{Invoking guix pull}).  This makes it possible to replicate a
Guix instance on a different machine or at a later point in time, which in
turn allows you to @emph{replicate complete software environments}, while
retaining precise @dfn{provenance tracking} of the software.

@node Invoking guix package
@section Invoking @command{guix package}

@cindex installing packages
@cindex removing packages
@cindex package installation
@cindex package removal
The @command{guix package} command is the tool that allows users to
install, upgrade, and remove packages, as well as rolling back to
previous configurations.  It operates only on the user's own profile,
and works with normal user privileges (@pxref{Features}).  Its syntax
is:

@example
guix package @var{options}
@end example

@cindex transactions
Primarily, @var{options} specifies the operations to be performed during
the transaction.  Upon completion, a new profile is created, but
previous @dfn{generations} of the profile remain available, should the user
want to roll back.

For example, to remove @code{lua} and install @code{guile} and
@code{guile-cairo} in a single transaction:

@example
guix package -r lua -i guile guile-cairo
@end example

@cindex aliases, for @command{guix package}
For your convenience, we also provide the following aliases:

@itemize
@item
@command{guix search} is an alias for @command{guix package -s},
@item
@command{guix install} is an alias for @command{guix package -i},
@item
@command{guix remove} is an alias for @command{guix package -r},
@item
@command{guix upgrade} is an alias for @command{guix package -u},
@item
and @command{guix show} is an alias for @command{guix package --show=}.
@end itemize

These aliases are less expressive than @command{guix package} and provide
fewer options, so in some cases you'll probably want to use @command{guix
package} directly.

@command{guix package} also supports a @dfn{declarative approach}
whereby the user specifies the exact set of packages to be available and
passes it @i{via} the @option{--manifest} option
(@pxref{profile-manifest, @option{--manifest}}).

@cindex profile
For each user, a symlink to the user's default profile is automatically
created in @file{$HOME/.guix-profile}.  This symlink always points to the
current generation of the user's default profile.  Thus, users can add
@file{$HOME/.guix-profile/bin} to their @code{PATH} environment
variable, and so on.
@cindex search paths
If you are not using Guix System, consider adding the
following lines to your @file{~/.bash_profile} (@pxref{Bash Startup
Files,,, bash, The GNU Bash Reference Manual}) so that newly-spawned
shells get all the right environment variable definitions:

@example
GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$HOME/.guix-profile/etc/profile"
@end example

In a multi-user setup, user profiles are stored in a place registered as
a @dfn{garbage-collector root}, which @file{$HOME/.guix-profile} points
to (@pxref{Invoking guix gc}).  That directory is normally
@code{@var{localstatedir}/guix/profiles/per-user/@var{user}}, where
@var{localstatedir} is the value passed to @code{configure} as
@code{--localstatedir}, and @var{user} is the user name.  The
@file{per-user} directory is created when @command{guix-daemon} is
started, and the @var{user} sub-directory is created by @command{guix
package}.

The @var{options} can be among the following:

@table @code

@item --install=@var{package} @dots{}
@itemx -i @var{package} @dots{}
Install the specified @var{package}s.

Each @var{package} may specify either a simple package name, such as
@code{guile}, or a package name followed by an at-sign and version number,
such as @code{guile@@1.8.8} or simply @code{guile@@1.8} (in the latter
case, the newest version prefixed by @code{1.8} is selected.)

If no version number is specified, the
newest available version will be selected.  In addition, @var{package}
may contain a colon, followed by the name of one of the outputs of the
package, as in @code{gcc:doc} or @code{binutils@@2.22:lib}
(@pxref{Packages with Multiple Outputs}).  Packages with a corresponding
name (and optionally version) are searched for among the GNU
distribution modules (@pxref{Package Modules}).

@cindex propagated inputs
Sometimes packages have @dfn{propagated inputs}: these are dependencies
that automatically get installed along with the required package
(@pxref{package-propagated-inputs, @code{propagated-inputs} in
@code{package} objects}, for information about propagated inputs in
package definitions).

@anchor{package-cmd-propagated-inputs}
An example is the GNU MPC library: its C header files refer to those of
the GNU MPFR library, which in turn refer to those of the GMP library.
Thus, when installing MPC, the MPFR and GMP libraries also get installed
in the profile; removing MPC also removes MPFR and GMP---unless they had
also been explicitly installed by the user.

Besides, packages sometimes rely on the definition of environment
variables for their search paths (see explanation of
@code{--search-paths} below).  Any missing or possibly incorrect
environment variable definitions are reported here.

@item --install-from-expression=@var{exp}
@itemx -e @var{exp}
Install the package @var{exp} evaluates to.

@var{exp} must be a Scheme expression that evaluates to a
@code{<package>} object.  This option is notably useful to disambiguate
between same-named variants of a package, with expressions such as
@code{(@@ (gnu packages base) guile-final)}.

Note that this option installs the first output of the specified
package, which may be insufficient when needing a specific output of a
multiple-output package.

@item --install-from-file=@var{file}
@itemx -f @var{file}
Install the package that the code within @var{file} evaluates to.

As an example, @var{file} might contain a definition like this
(@pxref{Defining Packages}):

@lisp
@include package-hello.scm
@end lisp

Developers may find it useful to include such a @file{guix.scm} file
in the root of their project source tree that can be used to test
development snapshots and create reproducible development environments
(@pxref{Invoking guix environment}).

@item --remove=@var{package} @dots{}
@itemx -r @var{package} @dots{}
Remove the specified @var{package}s.

As for @code{--install}, each @var{package} may specify a version number
and/or output name in addition to the package name.  For instance,
@code{-r glibc:debug} would remove the @code{debug} output of
@code{glibc}.

@item --upgrade[=@var{regexp} @dots{}]
@itemx -u [@var{regexp} @dots{}]
@cindex upgrading packages
Upgrade all the installed packages.  If one or more @var{regexp}s are
specified, upgrade only installed packages whose name matches a
@var{regexp}.  Also see the @code{--do-not-upgrade} option below.

Note that this upgrades package to the latest version of packages found
in the distribution currently installed.  To update your distribution,
you should regularly run @command{guix pull} (@pxref{Invoking guix
pull}).

@item --do-not-upgrade[=@var{regexp} @dots{}]
When used together with the @code{--upgrade} option, do @emph{not}
upgrade any packages whose name matches a @var{regexp}.  For example, to
upgrade all packages in the current profile except those containing the
substring ``emacs'':

@example
$ guix package --upgrade . --do-not-upgrade emacs
@end example

@item @anchor{profile-manifest}--manifest=@var{file}
@itemx -m @var{file}
@cindex profile declaration
@cindex profile manifest
Create a new generation of the profile from the manifest object
returned by the Scheme code in @var{file}.  This option can be repeated
several times, in which case the manifests are concatenated.

This allows you to @emph{declare} the profile's contents rather than
constructing it through a sequence of @code{--install} and similar
commands.  The advantage is that @var{file} can be put under version
control, copied to different machines to reproduce the same profile, and
so on.

@c FIXME: Add reference to (guix profile) documentation when available.
@var{file} must return a @dfn{manifest} object, which is roughly a list
of packages:

@findex packages->manifest
@lisp
(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Use a specific package output.
       (list guile-2.0 "debug")))
@end lisp

@findex specifications->manifest
In this example we have to know which modules define the @code{emacs}
and @code{guile-2.0} variables to provide the right
@code{use-package-modules} line, which can be cumbersome.  We can
instead provide regular package specifications and let
@code{specifications->manifest} look up the corresponding package
objects, like this:

@lisp
(specifications->manifest
 '("emacs" "guile@@2.2" "guile@@2.2:debug"))
@end lisp

@item --roll-back
@cindex rolling back
@cindex undoing transactions
@cindex transactions, undoing
Roll back to the previous @dfn{generation} of the profile---i.e., undo
the last transaction.

When combined with options such as @code{--install}, roll back occurs
before any other actions.

When rolling back from the first generation that actually contains
installed packages, the profile is made to point to the @dfn{zeroth
generation}, which contains no files apart from its own metadata.

After having rolled back, installing, removing, or upgrading packages
overwrites previous future generations.  Thus, the history of the
generations in a profile is always linear.

@item --switch-generation=@var{pattern}
@itemx -S @var{pattern}
@cindex generations
Switch to a particular generation defined by @var{pattern}.

@var{pattern} may be either a generation number or a number prefixed
with ``+'' or ``-''.  The latter means: move forward/backward by a
specified number of generations.  For example, if you want to return to
the latest generation after @code{--roll-back}, use
@code{--switch-generation=+1}.

The difference between @code{--roll-back} and
@code{--switch-generation=-1} is that @code{--switch-generation} will
not make a zeroth generation, so if a specified generation does not
exist, the current generation will not be changed.

@item --search-paths[=@var{kind}]
@cindex search paths
Report environment variable definitions, in Bash syntax, that may be
needed in order to use the set of installed packages.  These environment
variables are used to specify @dfn{search paths} for files used by some
of the installed packages.

For example, GCC needs the @code{CPATH} and @code{LIBRARY_PATH}
environment variables to be defined so it can look for headers and
libraries in the user's profile (@pxref{Environment Variables,,, gcc,
Using the GNU Compiler Collection (GCC)}).  If GCC and, say, the C
library are installed in the profile, then @code{--search-paths} will
suggest setting these variables to @code{@var{profile}/include} and
@code{@var{profile}/lib}, respectively.

The typical use case is to define these environment variables in the
shell:

@example
$ eval `guix package --search-paths`
@end example

@var{kind} may be one of @code{exact}, @code{prefix}, or @code{suffix},
meaning that the returned environment variable definitions will either
be exact settings, or prefixes or suffixes of the current value of these
variables.  When omitted, @var{kind} defaults to @code{exact}.

This option can also be used to compute the @emph{combined} search paths
of several profiles.  Consider this example:

@example
$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths
@end example

The last command above reports about the @code{GUILE_LOAD_PATH}
variable, even though, taken individually, neither @file{foo} nor
@file{bar} would lead to that recommendation.


@item --profile=@var{profile}
@itemx -p @var{profile}
Use @var{profile} instead of the user's default profile.

@var{profile} must be the name of a file that will be created upon
completion.  Concretely, @var{profile} will be a mere symbolic link
(``symlink'') pointing to the actual profile where packages are
installed:

@example
$ guix install hello -p ~/code/my-profile
@dots{}
$ ~/code/my-profile/bin/hello
Hello, world!
@end example

All it takes to get rid of the profile is to remove this symlink and its
siblings that point to specific generations:

@example
$ rm ~/code/my-profile ~/code/my-profile-*-link
@end example

@item --list-profiles
List all the user's profiles:

@example
$ guix package --list-profiles
/home/charlie/.guix-profile
/home/charlie/code/my-profile
/home/charlie/code/devel-profile
/home/charlie/tmp/test
@end example

When running as root, list all the profiles of all the users.

@cindex collisions, in a profile
@cindex colliding packages in profiles
@cindex profile collisions
@item --allow-collisions
Allow colliding packages in the new profile.  Use at your own risk!

By default, @command{guix package} reports as an error @dfn{collisions}
in the profile.  Collisions happen when two or more different versions
or variants of a given package end up in the profile.

@item --bootstrap
Use the bootstrap Guile to build the profile.  This option is only
useful to distribution developers.

@end table

In addition to these actions, @command{guix package} supports the
following options to query the current state of a profile, or the
availability of packages: