@civodul would it be too complex for the main Guix repo to break out into specialized official channels for certain categories of packages that are not needed for producing a working system?
@daviwil@civodul I've wondered the same -- just looking at the size of say crates.scm or emacs-xyz.scm, at first blush they seem like good candidates for separate channels. Like https://github.com/babariviere/guix-emacs could be a good way to handle emacs, which iirc is managed by a specific Team in guix already.
But I also worry about cross dependencies, need to migrate packages from one channel to another, duplicate definitions, etc etc. Does it solve more problems than it creates?
@shtwzrd@daviwil Indeed, it’s really tricky: now that core packages like librsvg (and soon Linux) depend on Rust, you can’t just move Rust packages out of Guix.
The same goes for most language packages. For example, Pandoc is used by a variety of packages, and it pulls in lots of Haskell packages.
CRAN and Bioconductor might be good candidates, but then the difficult part would be dealing with compatibility and ensuring interested parties have a say.
@civodul@shtwzrd@daviwil One could ask if this is a technical (maintainability, stability, risk of unimportant commit breaking entire guix, etc) or social (different maintainer teams, different release schedules, expectations on quality/stability etc) challenge, but one deeper question is: how much is possible to isolate as a minimal computing base, and is that useful? It seems modern packages are more or less circularly dependent anyway.
@jas@daviwil@shtwzrd Good points. The separation as channels is both a technical and a social challenge (Conway’s law).
As for the minimal computing base, I find it sad that apart maybe from the BSDs, nobody is focusing on building a “system”. We end up with glibc depending on Python, GCC requiring a recent C++ compiler, etc.
Guix is focusing on building a system to a large extent, and perhaps the answer is to “own” its basic components.
@civodul Surely we could find an onion-ring model? Packages which make an absolutely minimal system at the core, a channel capable of building a small desktop system around that, etc, etc. The rings can likely be segmented as well, so scientific software and audio workbenches live side-by-side in the same ring.
@khleedril I’m afraid we can’t: sooner or later, the innermost ring starts depending on some outer ring (glibc depending on Python, librsvg on Rust, etc.), and you end up with a single ring.
Coming from Debian to Guix, having "everything" in a single repository is perhaps one of my favorite practical features.
Debian has no "central" location for VCS repositories, every single package defines a custom location, which could be entirely outside of Debian infrastructure, or no proper VCS at all!
Guix having everything in a monorepo enables searching for packages with "git grep" and also cargo-culting, er, borrowing from other packages much more easily.
Add comment