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

Previous Next

Full log

View this message in rfc822 format

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

Hi,

On Tue, 26 Nov 2024 at 15:42, Ludovic Courtès <ludo <at> gnu.org> wrote:

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

Yes, that’d be my suggestion: having a better filtering strategy for
’leaf-packages’…

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

…so yes, it appears to me better to have security for one, then maybe
one per team?  Or per updater?

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

You read in my dreams! ;-)

> The sky’s the limit!

Let touch the void…

Cheers,
simon

Previous Next

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