Hi, On 2026-10-27 at 16:37+01:00, Andreas Enge wrote: > On Tue, Oct 27, 2026 at 03:51:11PM +0100, Simon Tournier wrote: > > About this, it reminds me some ideas [1] discussed months ago: moving > > peripheral packages to channels (still maintained by Guix, but as > > separate repositories). > > > > Good candidates to be extracted seem the current Guix proper packages > > from CRAN and/or Bioconductor, then humanly maintain them into one or > > more dedicated channels – unrelated to the fully automated guix-cran and > > guix-bioc channels. > > I am very hesitant about this splitting idea, at least until I see a > working proposition. > > How is quality control supposed to work? Already now we have friction > between Guix proper and channels (this actually prompted GCD 006, > because guix-science complained about removal of packages in Guix proper). > For instance, assuming that a certain set of Python packages is moved > into a channel of its own and we want to update to python-3.13 in Guix > proper, how would we do that? Right now the Python team takes respons- > ibility for breakage in dependent packages (and they are not necessarily > happy about it). In the future, do we agree that Guix proper does the > update, and channels are responsible for following (or breaking)? And > then people might not even be able to do a "guix pull" anymore if their > channels file contains a broken channel? > > Or no package in Guix proper depends on Qt5 anymore, so we just remove it, > and other channels follow or not as they see fit?
I tried to entertain the splitting idea to make quality control more cooporatable a while ago [2], tl;dr the core channel needs to have tagged releases. On the build farm we'd have: A. Crust channels' master depending on latest core release, which is to be used by rolling end-users. B. Crust's master depending on core's master, for core's QA. This should be able to replace the topic branch workflow entirely. Any breakage found by B should be either C. Fixed if it's due to changes to core, or D. Filed as crust's backlog and resolved after the next core release. Satelite channels (not part of Guix proper) could follow the B process (on their own build farm), and choose to do C or D as appropriate. 1: https://yhetil.org/guix/[email protected]/t 2: https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00184.html Best wishes, Phong
