From: Simon Tournier <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Josselin Poiret <dev@jpoiret.xyz>,
Mathieu Othacehe <othacehe@gnu.org>,
Tobias Geerinckx-Rice <me@tobias.gr>,
Ricardo Wurmus <rekado@elephly.net>,
65866@debbugs.gnu.org, Christopher Baines <guix@cbaines.net>
Subject: [bug#65866] Bootstrapping without the daemon and all that
Date: Tue, 26 Sep 2023 19:04:33 +0200 [thread overview]
Message-ID: <CAJ3okZ3dE_0L5Ccg6r0QHpnOBLX6KEooAOcijKX-q26_E_fCJw@mail.gmail.com> (raw)
In-Reply-To: <87jzsd2fo5.fsf_-_@gnu.org>
Hi Ludo,
On Tue, 26 Sept 2023 at 16:05, Ludovic Courtès <ludo@gnu.org> wrote:
> > Moving the Git dependency to a daemon dependency tweaks a bit what we
> > control when “bootstrapping”, no? Maybe I misread or misunderstand a
> > point.
>
> The model in Guix is that there’s a daemon to “emulate” a build “from
> scratch”.
Yes and that "emulate" will be bigger.
> https://guix.gnu.org/en/blog/2019/reproducible-builds-summit-5th-edition/
> (under “Extreme Bootstrapping”)
Thanks for the reference. I have forgotten it. Yes, that's it. :-)
Adding Git as dependency to the daemon is adding Git in the Trusted
Computing Base. It appears to me important to raise and to not hide
under the carpet. :-)
> (The ‘wip-system-bootstrap’ branch still exists!)
Having a potential solution does not make pointless the current concern. ;-)
> Anyway, we’re drifting away from this patch series!
No, it is not drifting. The addition of Git in the trusting trust
story cannot be dismissed, IMHO.
It is not drifting to discuss for reaching some consensus about the
"risk" of enlarging the trusting trust computing base. For example,
is this "risk" worth the corner case of Guile-GnuTLS?
As I said elsewhere, adding something is often much easier than
removing something. Here the addition of Git has some implications
(libgit2, trusted computing base, etc.) and it is always about the
right balance. Do we have the right balance here? The discussion
about concrete concerns for the addition of Git as dependency helps in
reinforcing the consensus that this change is worth despite the
downsides.
To make it explicit: is this series worth the Guile-GnuTLS/Git
circular dependency corner case? Maybe it is already all clear for
you, and your answer is a big YES. :-) And perhaps it is the only
answer. :-) But it does not mean the answer is fully clear for
everybody, at least it is not necessary straightforward for me.
Somehow, do we have a consensus about the way that this series is
worth the Guile-GnuTLS/Git circular dependency corner case? And a
consensus about the way that this series is The Right Thing for that
circular dependency?
Cheers,
simon
next prev parent reply other threads:[~2023-09-26 17:06 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 14:23 [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Ludovic Courtès
2023-09-11 14:25 ` [bug#65866] [PATCH 1/8] git-download: Move fallback code to (guix build git) Ludovic Courtès
2023-09-20 16:05 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-20 16:40 ` Simon Tournier
2023-09-22 21:53 ` Ludovic Courtès
2023-09-11 14:25 ` [bug#65866] [PATCH 2/8] git-download: Honor the ‘GUIX_DOWNLOAD_FALLBACK_TEST’ environment variable Ludovic Courtès
2023-09-20 16:07 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-11 14:25 ` [bug#65866] [PATCH 3/8] perform-download: Remove unused one-argument clause Ludovic Courtès
2023-09-20 16:09 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-11 14:25 ` [bug#65866] [PATCH 4/8] daemon: Add “git-download” built-in builder Ludovic Courtès
2023-09-20 17:32 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-21 7:42 ` Ludovic Courtès
2023-09-22 22:27 ` [bug#65866] [PATCH v2 " Ludovic Courtès
2023-09-22 22:27 ` [bug#65866] [PATCH v2 1/8] git-download: Move fallback code to (guix build git) Ludovic Courtès
2023-09-25 8:15 ` Simon Tournier
2023-09-25 9:24 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Ludovic Courtès
2023-09-25 12:13 ` Simon Tournier
2023-09-22 22:27 ` [bug#65866] [PATCH v2 2/8] git-download: Honor the ‘GUIX_DOWNLOAD_FALLBACK_TEST’ environment variable Ludovic Courtès
2023-09-22 22:27 ` [bug#65866] [PATCH v2 3/8] perform-download: Remove unused one-argument clause Ludovic Courtès
2023-09-22 22:28 ` [bug#65866] [PATCH v2 4/8] daemon: Add “git-download” built-in builder Ludovic Courtès
2023-09-22 22:28 ` [bug#65866] [PATCH v2 5/8] build: Add dependency on Git Ludovic Courtès
2023-09-25 13:59 ` Simon Tournier
2023-09-26 14:05 ` [bug#65866] Bootstrapping without the daemon and all that Ludovic Courtès
2023-09-26 17:04 ` Simon Tournier [this message]
2023-10-12 10:54 ` Ludovic Courtès
2023-10-16 8:46 ` Simon Tournier
2023-09-22 22:28 ` [bug#65866] [PATCH v2 6/8] perform-download: Use the ‘git’ command captured at configure time Ludovic Courtès
2023-09-22 22:28 ` [bug#65866] [PATCH v2 7/8] git-download: Use “builtin:git-download” when available Ludovic Courtès
2023-09-25 8:33 ` Simon Tournier
2023-09-25 9:23 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Ludovic Courtès
2023-09-25 12:37 ` Simon Tournier
2023-09-25 12:48 ` Simon Tournier
2023-09-25 15:49 ` Maxim Cournoyer
2023-09-26 15:44 ` bug#65866: " Ludovic Courtès
2023-09-26 17:13 ` [bug#65866] " Simon Tournier
2023-10-01 15:02 ` Ludovic Courtès
2023-10-16 9:11 ` [bug#65866] Toward RFC? (was Re: [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts) Simon Tournier
2023-10-30 15:12 ` Ludovic Courtès
2023-09-22 22:28 ` [bug#65866] [PATCH v2 8/8] tests: Assume ‘git’ is always available Ludovic Courtès
2023-09-11 14:25 ` [bug#65866] [PATCH 5/8] build: Add dependency on Git Ludovic Courtès
2023-09-20 17:57 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-22 22:00 ` Ludovic Courtès
2023-09-25 15:59 ` Maxim Cournoyer
2023-09-11 14:25 ` [bug#65866] [PATCH 6/8] perform-git-download: Use the ‘git’ command captured at configure time Ludovic Courtès
2023-09-20 17:34 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-11 14:25 ` [bug#65866] [PATCH 7/8] git-download: Use “builtin:git-download” when available Ludovic Courtès
2023-09-20 17:50 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
2023-09-22 21:58 ` Ludovic Courtès
2023-09-25 15:56 ` Maxim Cournoyer
2023-09-11 14:25 ` [bug#65866] [PATCH 8/8] tests: Assume ‘git’ is always available Ludovic Courtès
2023-09-20 17:59 ` [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ3okZ3dE_0L5Ccg6r0QHpnOBLX6KEooAOcijKX-q26_E_fCJw@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=65866@debbugs.gnu.org \
--cc=dev@jpoiret.xyz \
--cc=guix@cbaines.net \
--cc=ludo@gnu.org \
--cc=me@tobias.gr \
--cc=othacehe@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).