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

[Denis 'GNUtoo' Carikli]

On Guix integration:
--------------------

On Fri, 22 Mar 2024 10:17:39 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> Side note, as an observer from outside, it also seems relevant how the
> project goal is different from Canoeboot.  Is the difference that GNU
> Boot seeks to integrate more with FSDG distros like Guix?
Right now our goal is more to work with upstream Guix to add packages in
Guix for what we need, and then use these packages to build the images
that we distribute in ftp.gnu.org/gnu/gnuboot. 

We already added grub-coreboot in Guix but we need to add more
(at least seabios-coreboot, and the Coreboot memtest86+, and Coreboot
itself if possible). Since both GNU Boot maintainers are also Guix
users, it also enable us to collaborate with Guix by sending patches and
through that somewhat share the maintenance with Guix of a very small
number of packages.

GNU Boot is also based on an older version of the Libreboot build
system that does everything with shell scripts, and we already adapted
it to be able to easily replace build commands (./configure, make) by
'guix shell' commands.

Since writing Guix packages is relatively easy and that Guix is well
documented, if contributors can use 'guix build', then the rest is
pretty straightforward and they can learn it step by step, by looking
at examples, asking other GNU Boot or Guix contributors for help, etc.

So this is why the integration of Guix as a dependency in GNU Boot is
something really crucial and that it has to be done right: we don't
want to loose contributors because there is too much setup, or because
our automatic way to install and update Guix fails.

What you suggested could indeed be the way to go: replace the code to
at least install and configure Guix with a pointer to the installation
section of the official Guix manual, and improve it along the way if we
need to (by mentioning more distro packages for instance). This should
take care of the substitutes configuration issue.

But then we would still like to somehow make guix time-machine
--commit=<hash> work automatically, so we need to somehow fetch that
revision, and if possible without touching the current guix revision
not to mess up the system of people that also use Guix for other
things. For that we probably need to add an option to guix pull and
upstream that. 

Since that could take some time, we could start by detecting if the
revision we need is not there and in that case at the same time point
users to the Guix manual to run guix pull, and warn about the issue of
changing guix revision, store the older guix revision in a well known
place and provide instructions to restore it.

As for supporting various guix build options (like '-c, --cores=N',
'--max-jobs=N'), we could probably make that configurable in GNU Boot
with the help of autotools.

> Guix also supports i686 more or less; it will not be dropped, so
> memory use can be trusted to not be more than i686 can do.
That's a good point. Once we build all our software with Guix,
doing that would also enable building on i686 for free[1].

Answers to your other questions:
--------------------------------
Another key difference with Canoeboot is that we also want to work
directly with various upstream projects like GRUB or Coreboot to make
sure we can keep maintaining the same devices over time. This decision
also probably aligns well with Guix goals as having too much extra
patch can be a burden to maintain and many distributions have formal or
informal policies to limit that to the strict minimum.

There are probably other differences as well (website build system,
etc) but they might not be very relevant to the use of Guix has a
mandatory dependency. Also note that GNU Boot is still pretty new (and
doesn't even have an official release yet) so over time there might be
more technical differences.

> Leah takes it personal, but on the Canoeboot FAQ, I find “GNU Boot
> does support downloading, deblobbing and re-compressing U-Boot
> archives, and in fact does a better job of *that* than Canoeboot in
> some ways, but it does not yet actually build U-Boot, and it does not
> boot U-Boot in any way, on any actual mainboards.”
If I understood right, Canoeboot dropped that functionality, and it's
still in the code of GNU Boot, but I wouldn't rely on that until GNU
Boot starts releasing deblobbed u-boot archives or that it's integrated
upstream in Guix in some form.

References:
-----------
[1]The FSDG distributions versions mentioned in the build documentation
   (https://www.gnu.org/software/gnuboot/web/docs/build/) do not
   support i686. Using Guix would fix that. All that is because we
   want to continue supporting the KGPE-D16 (that Guix also uses for its
   infrastructure), and that right now we use an older Coreboot
   revision for it, which requires older compiler revisions.

   We have plans for re-upstreaming this mainboard in Coreboot in a
   sustainable way (so it doesn't get dropped again) but in the future
   we might need help to complete that task that either with coding
   (we might be able to provide reverse engineered documentation to
   write maintainable code) or funding.

Denis.

pgpzn1ZcHO7dN.pgp
Description: OpenPGP digital signature