[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix as a non-optional dependency in another project, and Guix resou
From: |
pelzflorian (Florian Pelz) |
Subject: |
Re: Guix as a non-optional dependency in another project, and Guix resources requirements. |
Date: |
Mon, 25 Mar 2024 18:34:18 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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
- Guix as a non-optional dependency in another project, and Guix resources requirements., Denis 'GNUtoo' Carikli, 2024/03/19
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., pelzflorian (Florian Pelz), 2024/03/20
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., Denis 'GNUtoo' Carikli, 2024/03/21
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., pelzflorian (Florian Pelz), 2024/03/22
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., Denis 'GNUtoo' Carikli, 2024/03/25
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements.,
pelzflorian (Florian Pelz) <=
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., Denis 'GNUtoo' Carikli, 2024/03/26
- Re: Guix as a non-optional dependency in another project, and Guix resources requirements., pelzflorian (Florian Pelz), 2024/03/27
Re: Guix as a non-optional dependency in another project, and Guix resources requirements., Adrien 'neox' Bourmault, 2024/03/23