Hi, I'm one of the co-maintainers of GNU Boot, a project aimed at replace nonfree boot firmwares that comes with computers with fully free software. For that we reuse software like Coreboot, GRUB, SeaBIOS, etc that are combined into installable images. Most of the code is still inherited from the latest release(s) of Libreboot that produced fully free software releases and currently consists in shell scripts that build these software components (by running ./configure, make etc directly in the shell scripts). Right now we only use Guix as an optional dependency to build the website: if people use './configure --enable-guix', it uses 'guix time-machine [...] -- shell [...]' under the hood to make the build reproducible, install all dependencies, etc. Having Guix optional and not used by default means that people who use --enable-guix already have Guix installed and take know how to update it with guix pull. So if we have Guix as a non-optional dependency, if we take care of automatizing the installation and update of Guix, users would then be able to build GNU Boot directly without having to lean Guix basics first, and worry about learning Guix later on when they contribute to GNU Boot or Guix directly. My first tentative was to automatically install Guix from the host distribution package manager (if Guix is not already there) and update it to the revision we need (if it's not already at a more recent revision). So I took care (in script(s) that are run automatically) of different distros package managers (apt, pacman, yum, etc) and exporting the right variables / sourcing the right scripts, and I still need to handle distributions without a guix package and to enable the substitutes for new Guix installations. But beside that I'm not sure I'm on the right track because: - First and most importantly, running 'guix pull' can fail sometimes, especially if there is not enough RAM per core. A fix that work is to lower the number of cores used with 'guix pull -c 1 -M 1' for instance. But the issue is that I'm unsure how much RAM per core is needed. Maybe 2GiB or 3GiB? Also if users have heavy desktop usage (browser(s) with a ton of tabs open) could that value change? I could ask help from GNU Boot users for testing to find that value but maybe the Guix community already knows more about this. The big downside of my approach here is that if for some reason the script I made uses a 'memory per core' value that is too low, it would probably makes things way more difficult for contributors than having to read the Guix manual upfront in the first place, because it would fail and they won't understand why. So they'd need to understand both Guix, the code I wrote, and what caused the issue. - If Guix was already installed on a host distribution, I'm not sure how to handle substitutes. Ideally I'd like to be able to enable them just for GNU Boot and not change the way they are handled for other Guix usage. Also if substitutes are not used it probably affect the amount of RAM per core required. One way around here could be to build Guix ourselves and somehow find a way to have different defaults, but building that Guix could probably a long time. Are there projects that had similar issues / questions? Or is what I'm trying to do a can of worms and I'd better point users to the Guix manual instead? PS: Is this mail posted on the right mailing list? In one hand these questions are about Guix usage, but in another the people who might know the answer probably need to have a very good understanding of Guix internals and/or of how to write the Guix manual. Denis.