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: 5191 bytes --]

On Wed, 27 Mar 2024 12:22:40 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hi there.  [...]
Hi

> Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> writes:
> > 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.  
> 
> No, it does not fail.
Thanks a lot, this is very interesting as it could simplify a lot the
code. In addition running guix time-machine doesn't modify the current
Guix version so it's not invasive.

I recall that when I tried it on older versions of Guix, it did fail,
but maybe more recent versions don't fail anymore. I'd need to do more
tests with that to understand when it fails or doesn't fail and
somehow get/require the right conditions and then remove all the code
that isn't needed anymore.

> >> 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.  
> 
> So from reading the Guix build machinery, Makefile.am runs
> 
> https://git.savannah.gnu.org/cgit/guix.git/plain/build-aux/compile-all.scm
> 
> and they use (getenv "MAKEFLAGS") to check if make gets any
> --jobserver flag that specifies the number of parallel compilations.
> This seems slightly nicer than a non-standard configure option, but
> is also more complicated in that Makefile.am calls out to
> compile-all.scm to do the work.
Thanks for that information. This could make things work out of the box
without more configuration. Though I still need to think about that one
as the code is much harder to understand than with configuration
options.

> Why do you need so many different Guix versions?  Are there
> regressions or is it just that you have tried building different
> parts of Libreboot with different versions of Guix?
We don't necessarily need multiple Guix versions but I think it fits
better in the current design if we allow that.

The old structure of Libreboot we inherited was converted to look more
like packages. Now each "package" has a directory in resources/packages/
like resources/packages/grub for instance. And inside the package
directory there are shell scripts with specific names like download,
build that are tasks.

Because of that it makes sense to treat each "package" separately and
allow the use of different Guix versions. So practically speaking if I
want to replace the code that builds SeaBIOS with shell scripts I could
first write a local guix seabios-coreboot package that I add inside
resources/packages/seabios/seabios.scm and call guix build inside
resources/packages/seabios/payload (which builds SeaBIOS for Coreboot).
At this point I could use Guix 1.4.0 if there are no security issues in
SeaBIOS or its dependencies for Guix 1.4.0.

But once seabios-coreboot is upstreamed in Guix it would make sense to
get rid of resources/packages/seabios/seabios.scm completely if
possible (if we use the same build options, don't have extra patches,
etc) and instead update the shell script that calls guix build to use
the Guix version where seabios-coreboot was added.

Thanks to that it's easier to update each package without affecting the
rest.

When everything will have been converted to use Guix packages we would
need to think again if using a single Guix revision could make sense or
not depending on the amount of risk of breakages. The main advantage
of a single revision would be to have way faster builds.

> That is, you move Libreboot’s build system stepwise towards using guix
> build instead.  Sounds good from outside; I have not perused all the
> links throughly.  It is very interesting, though.
The main rationale behind that is to have at any point something that
still works. Using Guix just for specific packages like GRUB enable to
test the resulting images like with any other changes, and also
consistently update the documentation along the way and so on. We can
even write some automatic tests that work with images made before Guix
is integrated and after without needing any special consideration.

And finally it also lowers a lot the odds of having never-ending work to
do the conversion, and never finishing nor making any releases,
especially because some of the tasks (like building Coreboot) are not
trivial (it requires an ada compiler and Guix doesn't have one yet).

And all that also makes it easier to collaborate with upstream as we
don't need to rush to convert everything to Guix packages, so it leaves
time to upstream things.

Denis.

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