Next: Invoking guix lint, Previous: Invoking guix import, Up: Utilities [Contents][Index]
guix refresh
The primary audience of the guix refresh
command is developers
of the GNU software distribution. By default, it reports any packages
provided by the distribution that are outdated compared to the latest
upstream version, like this:
$ guix refresh gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1 gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
It does so by browsing each package’s FTP directory and determining the highest version number of the source tarballs therein. The command knows how to update specific types of packages: GNU packages, ELPA packages, etc.—see the documentation for --type below. The are many packages, though, for which it lacks a method to determine whether a new upstream release is available. However, the mechanism is extensible, so feel free to get in touch with us to add a new method!
When passed --update
, it modifies distribution source files to
update the version numbers and source tarball hashes of those packages’
recipes (see Defining Packages). This is achieved by downloading
each package’s latest source tarball and its associated OpenPGP
signature, authenticating the downloaded tarball against its signature
using gpg
, and finally computing its hash. When the public
key used to sign the tarball is missing from the user’s keyring, an
attempt is made to automatically retrieve it from a public key server;
when it’s successful, the key is added to the user’s keyring; otherwise,
guix refresh
reports an error.
The following options are supported:
--update
-u
Update distribution source files (package recipes) in place. This is usually run from a checkout of the Guix source tree (see Running Guix Before It Is Installed):
$ ./pre-inst-env guix refresh -s non-core
See Defining Packages, for more information on package definitions.
--select=[subset]
-s subset
Select all the packages in subset, one of core
or
non-core
.
The core
subset refers to all the packages at the core of the
distribution—i.e., packages that are used to build “everything
else”. This includes GCC, libc, Binutils, Bash, etc. Usually,
changing one of these packages in the distribution entails a rebuild of
all the others. Thus, such updates are an inconvenience to users in
terms of build time or bandwidth used to achieve the upgrade.
The non-core
subset refers to the remaining packages. It is
typically useful in cases where an update of the core packages would be
inconvenient.
--type=updater
-t updater
Select only packages handled by updater (may be a comma-separated list of updaters). Currently, updater may be one of:
gnu
the updater for GNU packages;
elpa
the updater for ELPA packages;
cran
the updater for CRAN packages;
pypi
the updater for PyPI packages.
For instance, the following commands only checks for updates of Emacs
packages hosted at elpa.gnu.org
and updates of CRAN packages:
$ guix refresh --type=elpa,cran gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0 gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
In addition, guix refresh
can be passed one or more package
names, as in this example:
$ ./pre-inst-env guix refresh -u emacs idutils gcc-4.8.4
The command above specifically updates the emacs
and
idutils
packages. The --select
option would have no
effect in this case.
When considering whether to upgrade a package, it is sometimes
convenient to know which packages would be affected by the upgrade and
should be checked for compatibility. For this the following option may
be used when passing guix refresh
one or more package names:
--list-updaters
-L
List available updaters and exit (see --type above.)
--list-dependent
-l
List top-level dependent packages that would need to be rebuilt as a result of upgrading one or more packages.
Be aware that the --list-dependent
option only
approximates the rebuilds that would be required as a result of
an upgrade. More rebuilds might be required under some circumstances.
$ guix refresh --list-dependent flex Building the following 120 packages would ensure 213 dependent packages are rebuilt: hop-2.4.0 geiser-0.4 notmuch-0.18 mu-0.9.9.5 cflow-1.4 idutils-4.6 …
The command above lists a set of packages that could be built to check
for compatibility with an upgraded flex
package.
The following options can be used to customize GnuPG operation:
--gpg=command
Use command as the GnuPG 2.x command. command is searched
for in $PATH
.
--key-download=policy
Handle missing OpenPGP keys according to policy, which may be one of:
always
Always download missing OpenPGP keys from the key server, and add them to the user’s GnuPG keyring.
never
Never try to download missing OpenPGP keys. Instead just bail out.
interactive
When a package signed with an unknown OpenPGP key is encountered, ask the user whether to download it or not. This is the default behavior.
--key-server=host
Use host as the OpenPGP key server when importing a public key.
Next: Invoking guix lint, Previous: Invoking guix import, Up: Utilities [Contents][Index]