[bug#74542] [PATCH 00/11] Improved tooling for package updates

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On Tue, 26 Nov 2024 at 11:32, Ludovic Courtès <ludo@gnu.org> wrote:

> This patch series aims to improve tooling for package upgrades:
>
>   • By adding a ‘--dependents’ option to ‘guix build’ to build
>     dependent packages (those returned by ‘guix refresh -l’).  This
>     was suggested by my colleague Romain Garbage, who also prototyped
>     a variant of this.
>
>   • By improving individual updaters and updating metadata for
>     some packages.

Cool!

>
>   • By adding an “upgrade manifest”, to automatically build the latest
>     version (using the ‘with-latest’ package transformation) of a few
>     security-critical packages along with their dependents at distance 2,
>     as well as some of the leaf packages.

I am more reserved here.

--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (define all-leafs (leaf-packages))
scheme@(guix-user)> (length all-leafs)
$2 = 13680
scheme@(guix-user)> (define leaf-to-updates
   (filter-map (lambda (package)
                 (and (memq (package-build-system package)
                            (list gnu-build-system cmake-build-system))
                      package))
               all-leafs))
scheme@(guix-user)> (length leaf-to-updates)
$3 = 2843
--8<---------------cut here---------------end--------------->8---

This list contains multiversion packages, for instance:

    "clang"
    "clang"
    "clang"
    "gccgo"
    "gccgo"
    "gccgo"
    "gccgo"
    "gccgo"
    "glibc"
    "glibc"
    "glibc"
    "glibc"
    "glibc"
    "glibc-locales"
    "glibc-locales-2.29"
    "glibc-locales-2.30"
    "glibc-locales-2.31"
    "glibc-locales-2.32"
    "glibc-locales-2.33"
    "glibc-locales-2.35"
    "linux-libre"
    "linux-libre"
    "linux-libre"
    "linux-libre"
    "linux-libre"
    "linux-libre-arm-generic"
    "linux-libre-arm-generic"
    "linux-libre-arm-generic"
    "linux-libre-arm-generic"
    "linux-libre-arm-omap2plus"
    "linux-libre-arm-omap2plus"
    "linux-libre-arm64-generic"
    "linux-libre-arm64-generic"
    "linux-libre-arm64-generic"
    "linux-libre-arm64-generic"
    "linux-libre-arm64-honeycomb"
    "linux-libre-documentation"
    "linux-libre-headers"
    "linux-libre-headers"
    "linux-libre-headers"
    "linux-libre-headers"
    "linux-libre-headers"
    "linux-libre-headers"
 

And this list also contains PyPI, for instance:

    "pyconfigure"
    "pypy"
    "python-cffi-documentation"
    "python-clingo-dl"
    "python-debug"
    "python-graph-tool"
    "python-libfreenect"
    "python-libmpsse"
    "python-libsvm"
    "python-next"
    "python-on-guile"
    "python-openturns"
    "python-sepolgen"
    "python2-dbus"
    "python2-minimal"

Maybe, we could be a bit more stringent on the list and filter out more
packages than only the ones based on build-systems.

Well, it could be helpful to avoid to burn resources for nothing.  For
example, it could be better to exclude the GitHub importer instead of
bypassing it with a wrong URL.

> Ludovic Courtès (11):
>   transformations: Export ‘package-with-upstream-version’.
>   gnu-maintenance: ‘import-html-release’ doesn’t abort upon HTTP 404.
>   gnu-maintenance: Savannah/Xorg updaters no longer abort on network
>     errors.
>   build: Add ‘--development’ option.
>   packages: Factorize ‘all-packages’.
>   guix build: Add ‘--dependents’.
>   import: gnome: Keep going upon HTTP errors.
>   gnu-maintenance: ‘gnu-ftp’ updater excludes GnuPG-hosted packages.
>   gnu: Update updater properties for GnuPG-related packages.
>   guix build: Validate that the file passed to ‘-m’ returns a manifest.
>   etc: Add upgrade manifest.

Let review patch by patch. :-)

Cheers,
simon