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

[pelzflorian (Florian Pelz)]

Hello, what you intend does sound very interesting.  As for “guix
time-machine”, I do not see the problem:

Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> writes:
> 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.

“guix time-machine” is confined to the store and does not leave traces,
like “guix build” and unlike “guix pull”.  It is basically “guix pull”
without traces.


> We already added grub-coreboot in Guix

Ahh that was your work, GNU Booters; great job!  (Although I have no
machine to try yet.)

> 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.

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.


> 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”.

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.

Regards,
Florian