[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] doc: Run guix refresh -l to find out about dependent package

From: Ludovic Courtès
Subject: Re: [PATCH] doc: Run guix refresh -l to find out about dependent packages.
Date: Thu, 28 Jul 2016 15:09:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

ng0 <address@hidden> skribis:

> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -328,6 +328,21 @@ extensions---or to the operating system kernel---e.g., 
> reliance on
>  @code{uname} or @file{/proc} files.
>  @item
> +Run @command{guix refresh --list-dependent} (@pxref{Invoking guix refresh})
> +to find out how many packages would rebuild based on your patch.
> +When your patch touches important or a big number of packages, it is
> +prefered to be applied on the git branch core-updates or core-updates-next.
> +
> address@hidden
> +guix refresh -l libgcrypt
> +Building the following 822 packages would ensure 2221 dependent packages
> +are rebuilt:
> address@hidden example
> +
> +This is a good example for a number which indicates that a change to
> +libgcrypt would not simply be applied on master.

‘guix refresh -l’ is already mentioned in that section:

The specific branch names are not mentioned, but that’s also because
this process is still in flux.  “core-updates” initially meant “updates
to the core”, where “core” designates GCC, libc, Binutils, and a few
other packages that make up the implicit inputs of gnu-build-system.

Python, libgcrypt, and similar packages are not “core” packages,
strictly speaking.  Ideally, we’d run ‘python-updates’,
‘libgcrypt-updates’, etc. branches, but whether we do this depends on
our build farm capacity and on its current load.

In short, I think it’s best not too give too many details about a
process that’s not set in stone.  :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]