Re: 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: 5837 bytes --]

On Mon, 25 Mar 2024 18:34:18 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hello, what you intend does sound very interesting.  As for “guix
> time-machine”, I do not see the problem [...]
Let's say a user install Guix 1.4.0 and GNU Boot use a guix commit after
v1.4.0, as I understand guix time-machine will fail.

Here we have code to detect that situation already, the issue is more
what to do when this situation happens.

A second problem is if a user install guix and runs guix pull right
after but doesn't run guix pull again, and that in the future we start
using commits/revisions newer than the ones the user had right after
running guix pull.

Especially in the second case, running an additional 'guix pull'
behind the back of the user can have some bad consequences if the user
is also using Guix for other things and for some reasons didn't plan to
update guix yet.

So my current plan is just to detect that the commit is not there and
tell the user to run guix pull and also give the user a way to restore
the old guix revision afterward if needed. It's not ideal but it could
work right now for all use cases.

> Simplifying install docs is being discussed and we would like more
> feedback:
> 
> https://issues.guix.gnu.org/69977
>
> At the same time, me citing the Arch Wiki’s negative stance on
> distros’ guix packages
> <https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00068.html>
> and the dealing with the recent Guix local privilege escalation
> vulnerability
> <https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00238.html>
> hopefully will not cost us our Debian package.
Thanks, I'll read all these threads.

> > 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.
> 
> I do not know, but maybe the Autotools of Guix itself use something
> like this to deal with “make -j4”.
My question was more about the user interface and if it was the right
thing to do. As for the code implementing it[1], it was pretty easy to
do for me and it integrates fine with the current GNU Boot structure: if
users run './autogen.sh && ./configure' they can still use the scripts
manually, so this avoids too much invasive changes.

I still need to do some cleanups though and complete that work (as some
things are still missing, like handling 'guix pull' to make sure that
guix-time-machine works).

[1]https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure

> I’m looking forward to reading much of the info you gave in this mail
> on a GNU Boot website, or if the info is there already I just missed
> it.
The issue is that there is a chicken and egg issue as for the
code/documentation to be merged in GNU Boot, we need to figure out the
questions I asked in this thread.

And there is also a second chicken and egg: we don't want to add a
dependency on Guix without a real use case that really requires Guix in
some non-optional way (more on that below).

As for the code that is actually merged, building the GNU Boot website
can be done with guix shell but to do that the user needs to pass
--enable-guix to the ./configure in that directory:
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/website-build

We used Guix shell here because it makes Guix optional, so we didn't
need to have the Guix part being ultra robust/polished/documented. If
it worked for users already familiar with Guix, it was good enough.

And we also already merged code to update Guix:
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/dependencies/guix
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/scripts/misc/guix.sh
but this is not run automatically, and not mentioned in the
documentation either. So users that know about it could run it manually
but that's pretty much it.

So in the meantime the code/documentation we have on Guix
non-optional integration in GNU Boot is available in various branches as
it is not ready yet.

And we don't want to make Guix non-optional for the website right now,
as it works fine in the way it is.

And the idea is to try to integrate Guix as a required dependency with
the least amount of changes. So it will probably be done to build some
tools first like with this branch:
https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure

This kind of changes really makes sense as it would enable us to fix
some installation instructions for some devices which would make the
first release closer, and it limits the risk of breakages since it
doesn't modify in any way the binaries to install.

As for deeper integration that can build GRUB with Guix, it can be found
here: https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix
Note that this branch is older and will probably be rebased / cleaned
up much later (probably after the release).

To get there we converted the Libreboot directory structures to
resemble more packages with tasks[2], and that is merged already. So
that enables us to then just remove the shell commands that build grub
and replace that with a call to guix build and keep the rest of the
shell commands that reuses the output.

[2]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=857afa42a8ade870115391b09d712b110e6a1066

It's done in this commit for instance:
https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?h=GNUtoo/guix&id=f96d93160d6c29cb45b999c56f03ec8a4312140d
But as explained before, this commit need to be rebased, split, cleaned
up, etc. For instance it was made at a time where grub-coreboot wasn't
in Guix yet, so now we can simply use the upstream package instead.

Denis.

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