Re: Stratification of GNU Guix into Independent Channels

[Liliana Marie Prikler]

Am Samstag, dem 24.12.2022 um 03:49 +0000 schrieb jgart:
> Hi Guixers,
> 
> I wanted to ask you what are your thoughts on this idea. This is a
> thought experiment at this stage.
> 
> Should GNU Guix be a small core of packages (and services?)?
No, it should be a functional operating system.

> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?
I think monorepo is a weird term to apply to Guix.  Yes, it is just a
single repository, but notably, it doesn't collect the sources of every
other package out there to put it into a single tree.  Instead, it
contains a recipe per package.  This makes it no different from Debian,
Arch, Gentoo, or any other package manager out there.

> GNU Guix proper would be a solid core of packages that is very easy
> to maintain. This would greatly reduce the maintenance burden since
> maintaining a world of rust, golang, or python packages is opt in by
> those who want to do that particular work.
No, it wouldn't.  Suppose this bootstrap Guix consisted only of
packages up to GCC.  Then any change to it would result in non-local
changes (and potential breakages) in every other channel in existence
and the local CI would never catch that.  As it currently stands, GCC
breaking some other package would be caught on core-updates.

> Users can opt out of certain channels. For example, there might be
> some users that want absolutely no rust or some other language or
> ecosystem of packages from being downloaded on their machine for
> whatever reason. Same goes for any other languages.
You can not opt out of Rust if you depend on librsvg.  In future, you
might not even be able to opt out of Rust when using the Linux kernel.
Yes, this is possibly the worst timeline to live in, but we need
solutions to actually deal with it, not burying our heads in sand.

> Would being subscribed to just the hypothetical small core channel in
> this proposal increase download/installation speeds given the
> availability of substitutes?
Not really, because for a functional system you would have to pull in
other channels.  With a stricter module layout we could possibly
modularize guix pull further, thus decreasing individual derivation
time, but that alone is a daunting task and not guaranteed to bring big
improvements.

What does work is convincing upstreams to pull in less dependencies and
drop the outdated ones, because that makes it so that eventually Guix
has to ship less packages.

Cheers