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

[Ludovic Courtès]

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:

  https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html

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.  :-)

Thoughts?

Ludo’.