Re: Automatically testing package updates

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

Hi,

That’s cool!  Here, I share a “random thought”. :-)

> This manifest is just an example.  We could come up with manifests
> targeting package collections like CRAN packages, astronomy packages,
> and so on.

Discussing on Mastodon, Konrad emitted this idea [1]:

        Just an idea from someone mostly ignorant about how the build
        farms work: could package builds be done lazily? E.g. the build
        farm tracks requests for yet-unbuilt packages, and builds those
        that have been requested ten times or so.

I know it’s not possible considering the current way substitutes are
designed.

The idea is still appealing; especially when using “guix time-machine”.

Currently and considering patch#74542 [2], the build farm will try to
build all the updates by upstream for some “defined” packages even if
these updates would never reach any branch or worse never land to
master.  If I understand correctly, the idea behind is to ease updates
and/or reviewing.  Yeah it should help. :-)

Consider Blender: many of all the updates are trivial updates.  But on
my relatively new laptop, it takes around 15 minutes to build.  It’s not
nothing and it might be a strong refrain [3] for updating and/or
reviewing the update.  Here is the past rate of the updates:

    5905b47287 gnu: blender: Update to 3.6.13. Sat Jul 6 00:52:44 2024 -0300
    ebaf658acd gnu: blender: Update to 3.6.10. Sat Apr 6 08:40:56 2024 -0300
    e8d163b49a gnu: blender: Update to 3.3.5. Fri Apr 14 15:11:51 2023 -0400
    eb169d36e5 gnu: blender: Update to 3.3.5. Fri Mar 31 13:29:29 2023 -0400
    45fe602602 gnu: blender: Update to 3.3.1. Sat Nov 19 19:54:14 2022 +0100
    f05f831f66 gnu: blender: Update to 3.0.1. Wed Feb 9 16:06:28 2022 +0100
    48d38125c2 gnu: blender: Update to 2.93.6. Sun Nov 21 18:37:50 2021 +0100

The idea of the manifest, if I understand correctly what’s behind, is to
ease that, then for example the versions 3.6.11 and 3.6.12 would have
been built by removing the constraint on having the capacity to locally
build.

That’s said, it appears to me a bazooka: build all just in case.

Because it’s not sure at all that someone™ would be motivated to commit
the Blender’s updates of 3.6.11 and 3.6.12; if we had the manifest
discussed before. :-)

Back to Konrad’s idea!

Consider that if instead of building all we would potentially need, we
only build what we really need.  That’s what QA tries to do: build all
the patches.  However, sometimes QA is lagging [4] or the number of
dependencies is too high.  Let put more <3 in QA!  Still.

Now, consider the case where we use "guix time-machine".  Today, the
substitutes availability depends on the weather. ;-) Well, sometimes
substitutes are still available, sometimes not; it depends on the cache
policy.  Indeed, we cannot store all binaries forever.

Therefore, consider the feature: When using "guix time-machine" on a
restricted set of channels, and so using specific revisions defined by
the channels, if the content-addressed item is not available, then it
would be possible to queue one or more or none transformations for some
packages from one specific revision of some channels we care.

This feature solves two problems at once: 1. avoid the bazooka but still
help by easing the reviewing of updates and 2. provide substitutes for
past revisions.

However, this needs to adapt how the mechanism for substituting works,
right?  The question seems: Is it doable or already doomed by current
design?  In other words, would it require too much work?


Cheers,
simon

1: https://social.sciences.re/@khinsen@scholar.social/113550338572274110

2: [bug#74542] [PATCH 11/11] etc: Add upgrade manifest.
Ludovic Courtès <ludo@gnu.org>
Tue, 26 Nov 2024 11:33:50 +0100
id:c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org
https://issues.guix.gnu.org/74542
https://issues.guix.gnu.org/msgid/c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org
https://yhetil.org/guix/c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org

3: Public guix offload server
Arun Isaac <arunisaac@systemreboot.net>
Thu, 21 Oct 2021 02:23:49 +0530
id:878rynh0yq.fsf@systemreboot.net
https://lists.gnu.org/archive/html/guix-devel/2021-10
https://yhetil.org/guix/878rynh0yq.fsf@systemreboot.net

4: https://social.sciences.re/@civodul@toot.aquilenet.fr/113549606095407968