On Tue, Oct 27, 2026 at 03:51:11PM +0100, Simon Tournier wrote: > About this, it reminds me some ideas [0,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? Otherwise, nothing would really change. If we keep a set of channels that need to be watched for breakage before merging a Python update or a Qt5 removal, this set would effectively be equivalent to the current monolithic Guix. Except that we would need to write extra code for monitoring the set of channels instead of only the main channel. Andreas
