On Wednesday, May 20th, 2026 at 4:28 AM, Nguyễn Gia Phong via "Development of
GNU Guix and the GNU System distribution." <[email protected]> wrote:
> On 2026-05-20 at 10:58+02:00, Ricardo Wurmus wrote:
> > Nguyễn Gia Phong <[email protected]> writes:
> > > 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?
> > >
> > > 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.
>
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. However,
I can see one problem with your suggestion that I don't know has been addressed
yet: 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,
but I suspect it hasn't been a real pain point yet because using multiple
channels on conjunction with the main guix one isn't common and the channels
that are used aren't pinning specific versions of the main guix channel.
Cheers,
Kaelyn
