The primary audience of the
guix refresh command is packagers.
As a user, you may be interested in the --with-latest option,
which can bring you package update superpowers built upon
refresh (see --with-latest). By default,
guix refresh 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
Alternatively, one can specify packages to consider, in which case a warning is emitted for packages that lack an updater:
$ guix refresh coreutils guile guile-ssh gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13
guix refresh browses the upstream repository of each package and determines
the highest version number of the releases therein. The command
knows how to update specific types of packages: GNU packages, ELPA
packages, etc.—see the documentation for --type below. There
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!
Consider the packages specified, and all the packages upon which they depend.
$ guix refresh --recursive coreutils gnu/packages/acl.scm:40:13: acl would be upgraded from 2.2.53 to 2.3.1 gnu/packages/m4.scm:30:12: 1.4.18 is already the latest version of m4 gnu/packages/xml.scm:68:2: warning: no updater for expat gnu/packages/multiprecision.scm:40:12: 6.1.2 is already the latest version of gmp …
Sometimes the upstream name differs from the package name used in Guix,
guix refresh needs a little help. Most updaters honor the
upstream-name property in package definitions, which can be used
to that effect:
(define-public network-manager (package (name "network-manager") ;; … (properties '((upstream-name . "NetworkManager")))))
When passed --update, it modifies distribution source files to
update the version numbers and source tarball hashes of those package
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
gpgv, and finally computing its hash—note that GnuPG must be
installed and in
guix install gnupg if needed.
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 this is successful, the key is added to the user’s keyring; otherwise,
guix refresh reports an error.
The following options are supported:
Consider the package expr evaluates to.
This is useful to precisely refer to a package, as in this example:
guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'
This command lists the dependents of the “final” libc (essentially all the packages).
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 -u
See Defining Packages, for more information on package definitions.
Select all the packages in subset, one of
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.
non-core subset refers to the remaining packages. It is
typically useful in cases where an update of the core packages would be
Select all the packages from the manifest in file. This is useful to check if any packages of the user manifest can be updated.
Select only packages handled by updater (may be a comma-separated list of updaters). Currently, updater may be one of:
the updater for GNU packages;
the updater for packages hosted at Savannah;
the updater for packages hosted at SourceForge;
the updater for GNOME packages;
the updater for KDE packages;
the updater for X.org packages;
the updater for packages hosted on kernel.org;
the updater for ELPA packages;
the updater for CRAN packages;
the updater for Bioconductor R packages;
the updater for CPAN packages;
the updater for PyPI packages.
the updater for RubyGems packages.
the updater for GitHub packages.
the updater for Hackage packages.
the updater for Stackage packages.
the updater for Crates packages.
the updater for Launchpad packages.
a generic updater that crawls the HTML page where the source tarball of the package is hosted, when applicable.
For instance, the following command only checks for updates of Emacs
packages hosted at
elpa.gnu.org and for 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
List available updaters and exit (see --type above).
For each updater, display the fraction of packages it covers; at the end, display the fraction of packages covered by all these updaters.
guix refresh can be passed one or more package
names, as in this example:
$ ./pre-inst-env guix refresh -u emacs idutils firstname.lastname@example.org
The command above specifically updates the
idutils packages. The --select option would have no
effect in this case. You might also want to update definitions that
correspond to the packages installed in your profile:
$ ./pre-inst-env guix refresh -u \ $(guix package --list-installed | cut -f1)
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 top-level dependent packages that would need to be rebuilt as a result of upgrading one or more packages.
reverse-package type of
guix graph, for information on how to visualize the list of
dependents of a package.
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: email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org …
The command above lists a set of packages that could be built to check
for compatibility with an upgraded
List all the packages which one or more packages depend upon.
$ guix refresh --list-transitive flex email@example.com depends on the following 25 packages: firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org …
The command above lists a set of packages which, when changed, would cause
flex to be rebuilt.
The following options can be used to customize GnuPG operation:
Use command as the GnuPG 2.x command. command is searched
Use file as the keyring for upstream keys. file must be in the
keybox format. Keybox files usually have a name ending in .kbx
and the GNU Privacy Guard (GPG) can manipulate these files
kbxutil in Using the GNU Privacy Guard, for
information on a tool to manipulate keybox files).
When this option is omitted,
guix refresh uses
~/.config/guix/upstream/trustedkeys.kbx as the keyring for upstream
signing keys. OpenPGP signatures are checked against keys from this keyring;
missing keys are downloaded to this keyring as well (see
You can export keys from your default GPG keyring into a keybox file using commands like this one:
gpg --export email@example.com | kbxutil --import-openpgp >> mykeyring.kbx
Likewise, you can fetch keys to a specific keybox file like this:
gpg --no-default-keyring --keyring mykeyring.kbx \ --recv-keys 27D586A4F8900854329FF09F1260E46482E63562
See --keyring in Using the GNU Privacy Guard, for more information on GPG’s --keyring option.
Handle missing OpenPGP keys according to policy, which may be one of:
Always download missing OpenPGP keys from the key server, and add them to the user’s GnuPG keyring.
Never try to download missing OpenPGP keys. Instead just bail out.
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.
Use host as the OpenPGP key server when importing a public key.
Add directory to the front of the package module search path (see Package Modules).
This allows users to define their own packages and make them visible to the command-line tools.
github updater uses the
GitHub API to query for new
releases. When used repeatedly e.g. when refreshing all packages,
GitHub will eventually refuse to answer any further API requests. By
default 60 API requests per hour are allowed, and a full refresh on all
GitHub packages in Guix requires more than this. Authentication with
GitHub through the use of an API token alleviates these limits. To use
an API token, set the environment variable
GUIX_GITHUB_TOKEN to a
token procured from https://github.com/settings/tokens or