Conversation

Notices

1. Embed this notice
   Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Thursday, 16-May-2024 20:51:35 JST Ludovic Courtès

   Recently (past week?), #Guix proper passed the 30K package limit, all free software!
   https://repology.org/repository/gnuguix

   • Embed this notice
     Simon Josefsson (jas@fosstodon.org)'s status on Thursday, 16-May-2024 21:37:10 JST Simon Josefsson

     in reply to

     • David Wilson
     • shtwzrd@mas.to:~$:idle:

     @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.

   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Thursday, 16-May-2024 21:37:10 JST Ludovic Courtès

     in reply to

     • David Wilson
     • Simon Josefsson
     • shtwzrd@mas.to:~$:idle:

     @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.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Thursday, 16-May-2024 21:37:14 JST Ludovic Courtès

     in reply to

     • David Wilson
     • shtwzrd@mas.to:~$:idle:

     @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.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     shtwzrd@mas.to:~$:idle: (shtwzrd@mas.to)'s status on Thursday, 16-May-2024 21:37:17 JST shtwzrd@mas.to:~$:idle:

     in reply to

     • David Wilson

     @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?

   • Embed this notice
     David Wilson (daviwil@fosstodon.org)'s status on Thursday, 16-May-2024 21:37:18 JST David Wilson

     in reply to

     @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?

   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Thursday, 16-May-2024 21:37:20 JST Ludovic Courtès

     in reply to

     How much should the package collection in Guix proper grow, though?

     There are consistency, QA, and sustainability challenges.

   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Thursday, 16-May-2024 21:37:21 JST Ludovic Courtès

     in reply to

     Third-party channels bring tens of thousands more packages.

     For scientific usage: https://hpc.guix.info/channels
     General purpose: https://toys.whereis.xn--q9jyb4c/channels