GNU bug report logs - #74542
[PATCH 00/11] Improved tooling for package updates

Previous Next

Full log

Message #41 received at 74542 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: 74542 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, Christopher Baines <guix <at> cbaines.net>,
 Josselin Poiret <dev <at> jpoiret.xyz>, Simon Tournier <zimon.toutoune <at> gmail.com>,
 Mathieu Othacehe <othacehe <at> gnu.org>
Subject: Re: [bug#74542] [PATCH 00/11] Improved tooling for package updates
Date: Tue, 26 Nov 2024 15:42:51 +0100

Ludovic Courtès <ludo <at> gnu.org> skribis:

> I already toyed with this idea here:
>
>   https://guix.bordeaux.inria.fr/jobset/guix-hpc-cutting-edge
>   https://gitlab.inria.fr/guix-hpc/guix-hpc/-/blob/master/cutting-edge.manifest?ref_type=heads
>
> It’s experimental; surely we’ll find that the manifest needs to be
> tweaked, or that some of the updaters abort to early.  But I think
> it can help, and it’s a good way to use available x86_64 CPU power
> at ci.guix.

Another point: having a single “upgrade manifest” probably won’t scale,
first because it takes time to evaluate it (looking for the latest
upstream version of all these packages), second because the jobset will
be messy if it contains tons of unrelated upgrades.

So I’m thinking that probably we’ll want focused upgrade manifests: one
for selected security-critical packages, one for the astronomy packages
so Sharlatan can save a bit on energy at home ;-), one for R packages,
and so on.

Another one I’d like to have: automatic ungrafting so that we could
apply ungrafting packages “anytime” (ideally!).

The sky’s the limit!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.