Hello Guix, On 2026-04-28 at 19:18+09:00, Nguyễn Gia Phong wrote: > On 2026-04-28 at 10:55+02:00, Ricardo Wurmus wrote: > > I can't help but look with envy at the automated > > guix-cran and guix-bioc channels that get updated every day. > > It's not ideal that the "blessed" collection of R packages > > in the main Guix channel is less fresh. > > Wouldn't it be possible then to split all R packages > to a separate channel, say guix-r that depends on guix, > then either (if possible) have guix depends on guix-r, > or bless a guix-meta channel that depends on both guix > and guix-r?
I analyzed the official channel's dependency graph and it turns out quite some R packages are inputs of non-R ones, so the split would not be completely clean, however, if we do 300-dependent cutoffs, we would have 4 "rings" going inward of 30722, 1775, 348 and 49 packages (the number could change a bit since I used last week's master, I'll follow up with the reprod scripts shortly). If each "ring" is split into graph components (two nodes are connected if they are in the same ring and one is an input of the other), the outer most layer still have a 26130-package component, and this is what I mean by unclean splitting in the paragraph above. Other "rings" also have unbalance component sizes. However, with most packages can be fixed directly without staging, we can restructure the QA process to be more efficient. On 2026-05-20 at 18:09+00:00, Kaelyn wrote: > On Wednesday, May 20th, 2026 at 4:28 AM, Nguyễn Gia Phong wrote: > > On 2026-05-20 at 10:58+02:00, Ricardo Wurmus wrote: > > > Nguyễn Gia Phong writes: > > > > With dependent channels pinning the core, we can update > > > > packages with many dependents with less friction. > > > > > > I really don't know if that's a feasible approach. > > > > > > I wondered if perhaps I should stop rebasing the r-team branch and > > > switch to a merge workflow, so that people who want the latest R > > > stuff could just switch to the r-team branch instead of having to > > > use a separate channel. > > > > > > A purely additive channel doesn't allow me to upgrade packages in > > > the main channel, such as "arrow" or rust things. > > > > One additive channel wouldn't, but I imagine many would bring down > > the dependent count of the core packages. Basically, instead > > of the */pinned packages, dependent channels could pin the core one > > and update it monthly or quarterly. > I can see one problem with your suggestion [...]: how is > the core channel handled when a use is combining multiple > dependent channels and those channels pin different versions > of the core channel? AFAIK it is currently handled > by manually resolving the conflicts in some fashion Hence, I'm proposing something simpler this time Here let's call the official user-facing channel, currently at <https://codeberg.org/guix/guix>, <guix> for short. The innermost "ring" is then referred to as <ring-0>, then <ring-1>, <ring-2>, and <ring-3>. In this message, I will consider a release branch (e.g. version-1.5.0) of a ring channel as something not causing any rebuild in its dependant channel, i.e. only grafts can land on ring 0 to 2's release branches, while <ring-3> can take whatever. <guix>'s master is an alias to <ring-3>'s highest version-n branch, and once this branch stops receiving updates, <guix>'s version-n branch is created still pointing to <ring-3>'s version-n. The reason behind this shall soon be obvious. <ring-i+1>'s version-n intuitively depends on <ring-i>'s version-n though. With all the boring parts laid out, let's finally tackle our issues. On Fri, 22 May 2026 at 12:21, Andreas Enge wrote: > there is a general problem of us having many world rebuild branches, > and not enough build power to handle them quickly (plus occasional > interruptions of the tools, like when we upgraded bayfront). On 2026-06-15 at 15:55+02:00, Hugo Buddelmeijer wrote: > During the Python 3.12 migration, my machine was essentially > world-rebuilding non-stop, because by the time it was finished, > we refreshed packages early in the chain, or we rebased. The first problem is the topic branch rush due to the social pressure to get the branch off the queue ASAP because other teams are also waiting. The other being the waste of rebuilds: On 2026-05-22 at 13:59+02:00, Simon Tournier wrote: > 'r-seurat' will be rebuilt by the Python-world rebuild, > then [R-world, World-world, Haskell-world rebuilds]. > Here, at least 3 rebuilds of 'r-seurat' are temporary > and known apriori to be wasted. In [1], the example > is about 521 packages [...] would be rebuilt 3 times > for (almost) no gain. > > Minimizing at the extreme ends to the 'core-updates' branch > (= put all the world-rebuild changes and rebuild the whole > only once) and we remind why we dropped it! ;-) > 1: Naming “build train” instead of “merge train”? > https://lists.gnu.org/r/guix-devel/2024-09/msg00054.html IIUC the current process is because the development branch *is* the user-facing channel, and thus changes (potentially) causes package breakages cannot land there (plus their dependants would lack substitutes for days). Instead of letting teams going dark only to resurface with hundreds of commits applied to the topic branch through a completely different process to those landing directly to master, allow changes to land to <ring-i>'s master branch as long as they don't break their own ring. Any breakage to their direct dependants on <ring-i+1>'s master must be filed as an issue proactively. This <ring-i+i>'s master however, depends on <ring-i>'s latest release version-n. <ring-0> must release periodically, possibly in the same _cycle_ as <guix>. Once <ring-i>'s version-n+1 is out, <ring-i+i>'s master immediately switch to depend on it. The logic here is the master branch of any ring is not ready to be consumed by any user or other channel. In particular, when <ring-2>'s version-n+1 is out, <guix>'s version-n is finally created to track <ring-3>'s version-n, which now must be frozen and at the mean time is still tracked by <guix>'s master. When packages on <ring-3>'s master (which now depends on <ring-2>'s version-n+1) are functional, it branches into version-n+1 and <guix>'s master switch to it. On 2026-06-16 at 18:50+00:00, Greg Hogan wrote: > I have not seen a response to the earlier proposal to find compromise > by allowing both with-LLM and without-LLM channels within the project, > sharing a common core. This proposal also fails to fragment the package collection for political reasons like LLM usages and non-free blobs. Such channel split, if happens, still need to be done by hand, but the stable ring releases shall make it easier. On 2026-05-20 at 18:09+00:00, Kaelyn wrote: > In general I like the idea of making greater use of multiple channels > and larger numbers of overall-smaller channels (which would hopefully > also help drive improvements around handling multiple channels > and computing channel derivations). It could even allow for some > small channels to spring up offering trimmed down or more aggressively > optimized variants of different packages, without risking flooding > the core channel with many variant packages. AFAIK most package variants in the official channel are to serve packaging purposes, not specific target or use cases like Gentoo's USE flags. I think supporting them is an orthogonal discussion to this one, even though they both touch on channels. (BTW Kaelyn could you disable encryption when sending out to public lists? I'm glad that my WKD is working, but I don't have PGP set up on all devices to decrypt what are already available on the archive in plain text.) Best wishes, Phong
signature.asc
Description: PGP signature
