Guix as a non-optional dependency in another project, and Guix resources requirements.

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]