GNU bug report logs - #65866
[PATCH 0/8] Add built-in builder for Git checkouts

Previous Next

Full log

Message #178 received at 65866 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>,
 65866 <at> debbugs.gnu.org, Christopher Baines <guix <at> cbaines.net>
Subject: Re: [bug#65866] Bootstrapping without the daemon and all that
Date: Mon, 16 Oct 2023 10:46:06 +0200

Hi Ludo,

On Thu, 12 Oct 2023 at 12:54, Ludovic Courtès <ludo <at> gnu.org> wrote:

>> 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?
>
> One thing I probably didn’t explain clearly is that yes, the circular
> dependency issue is one we have to solve.  For years, I hope we could
> avoid it but experience has shown that no, it’s a problem we did have to
> address.

There is different ways to solve this circular dependency.


> One example is Guile-GnuTLS being built from a Git checkout.  Another
> one is Hurd packages in commencement.scm built from a Git checkout.  We
> had to go to great lengths to avoid ‘git-fetch’:
>
>   https://issues.guix.gnu.org/64708#6

Somehow, I think it is the direction to explore: have some
’git-fetch-bootstrap’ which relies on some ’builtin:git-download’ and
guix-daemon side code, and then that being used to have the packages
required by some ’git-fetch’ without guix-daemon side code.

Doing so, we would minimize the opaque – hard to audit – code, which
means less power to guix-daemon, we keep the control, etc.  It appears
to me more consistent with the general approach elsewhere.  Anyway.

Rehashing all, your opinion was already made when you sent this patch.
You wrote since the very beginning on 6 May 2023 for Guile-GnuTLS [1]:

        The longer-term solution is to add a “builtin:git-download”
        derivation builder, just like we have “builtin:download”.  The
        implementation should be relatively easy, but we’ll have to be
        able to deal with daemons that lack this builtin possibly for
        several years.

        https://issues.guix.gnu.org/63331#0

Therefore, this patch was not an open discussion for some design but the
review of some code for fixing concrete issues.  No hard feeling, we
need to make progress after all; the issue is pending since months.
However, when giving a look at this patch, it was not my expectations.

It is my own mistake to have not been enough active before with the
issue.  I had months to discuss some design for the circular
dependencies of the fetching methods.  Since I am spending some time
reading about what is going on with Guix, I think we have a failure in
some process.

IMHO, we are missing a Request For Comments and I will send a proposal
for some implementation details this week.

Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.