[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:
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’.