Next: Substitutos, Previous: Recursos, Up: Gerenciamento de pacote [Contents][Index]
guix packageThe guix package command is the tool that allows users to install,
upgrade, and remove packages, as well as rolling back to previous
configurations. These operations work on a user profile—a directory
of installed packages. Each user has a default profile in
$HOME/.guix-profile. The command operates only on the user’s own
profile, and works with normal user privileges (see Recursos). Its
syntax is:
guix package opções
Primarily, options specifies the operations to be performed during the transaction. Upon completion, a new profile is created, but previous generations of the profile remain available, should the user want to roll back.
For example, to remove lua and install guile and
guile-cairo in a single transaction:
guix package -r lua -i guile guile-cairo
For your convenience, we also provide the following aliases:
guix search is an alias for guix package -s,
guix install is an alias for guix package -i,
guix remove is an alias for guix package -r,
guix upgrade is an alias for guix package -u,
guix show is an alias for guix package --show=.
These aliases are less expressive than guix package and provide
fewer options, so in some cases you’ll probably want to use guix
package directly.
guix package also supports a declarative approach whereby
the user specifies the exact set of packages to be available and passes it
via the --manifest option (see --manifest).
For each user, a symlink to the user’s default profile is automatically
created in $HOME/.guix-profile. This symlink always points to the
current generation of the user’s default profile. Thus, users can add
$HOME/.guix-profile/bin to their PATH environment variable, and
so on.
If you are not using Guix System, consider adding the following lines to
your ~/.bash_profile (see Bash Startup Files in The GNU Bash
Reference Manual) so that newly-spawned shells get all the right
environment variable definitions:
GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$GUIX_PROFILE/etc/profile"
In a multi-user setup, user profiles are stored in a place registered as a
garbage-collector root, which $HOME/.guix-profile points to
(see Invocando guix gc). That directory is normally
localstatedir/guix/profiles/per-user/user, where
localstatedir is the value passed to configure as
--localstatedir, and user is the user name. The
per-user directory is created when guix-daemon is started,
and the user sub-directory is created by guix package.
The options can be among the following:
--install=package …-i package …Install the specified packages.
Each package may specify a simple package name, such as guile,
optionally followed by an at-sign and version number, such as
guile@3.0.7 or simply guile@3.0. In the latter case, the
newest version prefixed by 3.0 is selected.
If no version number is specified, the newest available version will be
selected. In addition, such a package specification may contain a
colon, followed by the name of one of the outputs of the package, as in
gcc:doc or binutils@2.22:lib (see Pacotes com múltiplas saídas).
Packages with a corresponding name (and optionally version) are searched for among the GNU distribution modules (see Módulos de pacote).
Alternatively, a package can directly specify a store file name such
as /gnu/store/...-guile-3.0.7, as produced by, e.g., guix
build.
Sometimes packages have propagated inputs: these are dependencies that
automatically get installed along with the required package
(see propagated-inputs in
package objects, for information about propagated inputs in package
definitions).
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 --search-paths below). Any missing or possibly incorrect environment variable definitions are reported here.
--install-from-expression=exp-e expInstall the package exp evaluates to.
exp must be a Scheme expression that evaluates to a <package>
object. This option is notably useful to disambiguate between same-named
variants of a package, with expressions such as (@ (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.
--install-from-file=file-f arquivoInstall the package that the code within file evaluates to.
As an example, file might contain a definition like this (see Definindo pacotes):
(use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+))
Developers may find it useful to include such a guix.scm file in the
root of their project source tree that can be used to test development
snapshots and create reproducible development environments (see Invoking guix shell).
The file may also contain a JSON representation of one or more package
definitions. Running guix package -f on hello.json with the
following contents would result in installing the package greeter
after building myhello:
[
{
"name": "myhello",
"version": "2.10",
"source": "mirror://gnu/hello/hello-2.10.tar.gz",
"build-system": "gnu",
"arguments": {
"tests?": false
}
"home-page": "https://www.gnu.org/software/hello/",
"synopsis": "Hello, GNU world: An example GNU package",
"description": "GNU Hello prints a greeting.",
"license": "GPL-3.0+",
"native-inputs": ["gettext"]
},
{
"name": "greeter",
"version": "1.0",
"source": "https://example.com/greeter-1.0.tar.gz",
"build-system": "gnu",
"arguments": {
"test-target": "foo",
"parallel-build?": false,
},
"home-page": "https://example.com/",
"synopsis": "Greeter using GNU Hello",
"description": "This is a wrapper around GNU Hello.",
"license": "GPL-3.0+",
"inputs": ["myhello", "hello"]
}
]
--remove=package …-r pacote …Remove the specified packages.
As for --install, each package may specify a version number
and/or output name in addition to the package name. For instance, ‘-r
glibc:debug’ would remove the debug output of glibc.
--upgrade[=regexp …] ¶-u [regexp …]Upgrade all the installed packages. If one or more regexps are specified, upgrade only installed packages whose name matches a regexp. Also see the --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 guix pull (see Invocando guix pull).
When upgrading, package transformations that were originally applied when creating the profile are automatically re-applied (see Opções de transformação de pacote). For example, assume you first installed Emacs from the tip of its development branch with:
guix install emacs-next --with-branch=emacs-next=master
Next time you run guix upgrade, Guix will again pull the tip of
the Emacs development branch and build emacs-next from that checkout.
Note that transformation options such as --with-branch and --with-source depend on external state; it is up to you to ensure that they work as expected. You can also discard a transformations that apply to a package by running:
guix install package
--do-not-upgrade[=regexp …]When used together with the --upgrade option, do not upgrade any packages whose name matches a regexp. For example, to upgrade all packages in the current profile except those containing the substring “emacs”:
$ guix package --upgrade . --do-not-upgrade emacs
--manifest=arquivo ¶-m arquivoCreate a new generation of the profile from the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.
This allows you to declare the profile’s contents rather than constructing it through a sequence of --install and similar commands. The advantage is that file can be put under version control, copied to different machines to reproduce the same profile, and so on.
file must return a manifest object, which is roughly a list of packages:
(use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Usa uma saída de pacote específica. (list guile-2.0 "debug")))
See Writing Manifests, for information on how to write a manifest. See --export-manifest, to learn how to obtain a manifest file from an existing profile.
--roll-back ¶Roll back to the previous generation of the profile—i.e., undo the last transaction.
When combined with options such as --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 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.
--switch-generation=padrão ¶-S padrãoSwitch to a particular generation defined by pattern.
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 --roll-back, use --switch-generation=+1.
The difference between --roll-back and --switch-generation=-1 is that --switch-generation will not make a zeroth generation, so if a specified generation does not exist, the current generation will not be changed.
--search-paths[=tipo] ¶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 search paths for files used by some of the installed packages.
For example, GCC needs the CPATH and LIBRARY_PATH environment
variables to be defined so it can look for headers and libraries in the
user’s profile (see Environment Variables in Using the GNU Compiler
Collection (GCC)). If GCC and, say, the C library are installed in the
profile, then --search-paths will suggest setting these variables
to profile/include and profile/lib, respectively
(see Search Paths, for info on search path specifications associated
with packages.)
The typical use case is to define these environment variables in the shell:
$ eval $(guix package --search-paths)
kind may be one of exact, prefix, or 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, kind defaults to exact.
This option can also be used to compute the combined search paths of several profiles. Consider this example:
$ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths
The last command above reports about the GUILE_LOAD_PATH variable,
even though, taken individually, neither foo nor bar would
lead to that recommendation.
--profile=perfil-p perfilUse profile instead of the user’s default profile.
profile must be the name of a file that will be created upon completion. Concretely, profile will be a mere symbolic link (“symlink”) pointing to the actual profile where packages are installed:
$ guix install hello -p ~/code/my-profile … $ ~/code/my-profile/bin/hello Hello, world!
All it takes to get rid of the profile is to remove this symlink and its siblings that point to specific generations:
$ rm ~/code/my-profile ~/code/my-profile-*-link
--list-profilesList all the user’s profiles:
$ guix package --list-profiles /home/charlie/.guix-profile /home/charlie/code/my-profile /home/charlie/code/devel-profile /home/charlie/tmp/test
When running as root, list all the profiles of all the users.
--allow-collisionsAllow colliding packages in the new profile. Use at your own risk!
By default, guix package reports as an error collisions in
the profile. Collisions happen when two or more different versions or
variants of a given package end up in the profile.
--bootstrapUse the bootstrap Guile to build the profile. This option is only useful to distribution developers.
In addition to these actions, guix package supports the following
options to query the current state of a profile, or the availability of
packages:
List the available packages whose name, synopsis, or description matches
regexp (in a case-insensitive fashion), sorted by relevance. Print
all the metadata of matching packages in recutils format (see GNU recutils databases in GNU recutils manual).
This allows specific fields to be extracted using the recsel
command, for instance:
$ guix package -s malloc | recsel -p name,version,relevance name: jemalloc version: 4.5.0 relevance: 6 name: glibc version: 2.25 relevance: 1 name: libgc version: 7.6.0 relevance: 1
Similarly, to show the name of all the packages available under the terms of the GNU LGPL version 3:
$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"' name: elfutils name: gmp …
It is also possible to refine search results using several -s flags
to guix package, or several arguments to guix search.
For example, the following command returns a list of board games (this time
using the guix search alias):
$ guix search '\<board\>' game | recsel -p name name: gnubg …
If we were to omit -s game, we would also get software packages that
deal with printed circuit boards; removing the angle brackets around
board would further add packages that have to do with keyboards.
And now for a more elaborate example. The following command searches for cryptographic libraries, filters out Haskell, Perl, Python, and Ruby libraries, and prints the name and synopsis of the matching packages:
$ guix search crypto library | \
recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
See Selection Expressions in GNU recutils manual, for more
information on selection expressions for recsel -e.
Show details about package, taken from the list of available packages,
in recutils format (see GNU recutils databases in GNU recutils manual).
$ guix package --show=guile | recsel -p name,version name: guile version: 3.0.5 name: guile version: 3.0.2 name: guile version: 2.2.7 …
You may also specify the full name of a package to only get details about a
specific version of it (this time using the guix show alias):
$ guix show guile@3.0.5 | recsel -p name,version name: guile version: 3.0.5
List the currently installed packages in the specified profile, with the most recently installed packages shown last. When regexp is specified, list only installed packages whose name matches regexp.
For each installed package, print the following items, separated by tabs:
the package name, its version string, the part of the package that is
installed (for instance, out for the default output, include
for its headers, etc.), and the path of this package in the store.
List packages currently available in the distribution for this system (see Distribuição GNU). When regexp is specified, list only available packages whose name matches regexp.
For each package, print the following items separated by tabs: its name, its version string, the parts of the package (see Pacotes com múltiplas saídas), and the source location of its definition.
Return a list of generations along with their creation dates; for each generation, show the installed packages, with the most recently installed packages shown last. Note that the zeroth generation is never shown.
For each installed package, print the following items, separated by tabs: the name of a package, its version string, the part of the package that is installed (see Pacotes com múltiplas saídas), and the location of this package in the store.
When pattern is used, the command returns only matching generations. Valid patterns include:
And --list-generations=1,8,2 outputs three generations in the specified order. Neither spaces nor trailing commas are allowed.
It is also possible to omit the endpoint. For example, --list-generations=2.., returns all generations starting from the second one.
When pattern is omitted, delete all generations except the current one.
This command accepts the same patterns as --list-generations. When pattern is specified, delete the matching generations. When pattern specifies a duration, generations older than the specified duration match. For instance, --delete-generations=1m deletes generations that are more than one month old.
If the current generation matches, it is not deleted. Also, the zeroth generation is never deleted.
Note that deleting generations prevents rolling back to them. Consequently, this command must be used with care.
Write to standard output a manifest suitable for --manifest corresponding to the chosen profile(s).
This option is meant to help you migrate from the “imperative” operating
mode—running guix install, guix upgrade, etc.—to the
declarative mode that --manifest offers.
Be aware that the resulting manifest approximates what your profile actually contains; for instance, depending on how your profile was created, it can refer to packages or package versions that are not exactly what you specified.
Keep in mind that a manifest is purely symbolic: it only contains package names and possibly versions, and their meaning varies over time. If you wish to “pin” channels to the revisions that were used to build the profile(s), see --export-channels below.
Write to standard output the list of channels used by the chosen profile(s),
in a format suitable for guix pull --channels or guix
time-machine --channels (see Canais).
Together with --export-manifest, this option provides information allowing you to replicate the current profile (see Replicating Guix).
However, note that the output of this command approximates what was actually used to build this profile. In particular, a single profile might have been built from several different revisions of the same channel. In that case, --export-manifest chooses the last one and writes the list of other revisions in a comment. If you really need to pick packages from different channel revisions, you can use inferiors in your manifest to do so (see Inferiores).
Together with --export-manifest, this is a good starting point if you are willing to migrate from the “imperative” model to the fully declarative model consisting of a manifest file along with a channels file pinning the exact channel revision(s) you want.
Finally, since guix package may actually start build processes, it
supports all the common build options (see Opções de compilação comum). It
also supports package transformation options, such as
--with-source, and preserves them across upgrades (see Opções de transformação de pacote).
Next: Substitutos, Previous: Recursos, Up: Gerenciamento de pacote [Contents][Index]