GNU bug report logs - #54304
[PATCH] Don't fix git executable location during Elixir build

Previous Next

Full log

View this message in rfc822 format

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Cees de Groot <cg <at> evrl.com>, Maxime Devos <maximedevos <at> telenet.be>
Cc: 54304 <at> debbugs.gnu.org
Subject: [bug#54304] [PATCH] Don't fix git executable location during Elixir build
Date: Wed, 09 Mar 2022 17:59:03 +0000

On 9 March 2022 17:35:25 UTC, Cees de Groot <cg <at> evrl.com> wrote:
>> Propagation is not necessary to ‘keep git around’ (assuming that the
>
>Well.... the whole reason that I stumbled upon this was that the compile-time substitution referred to a Git version that got GC'd.

This simply Should Not happen.  Guix's GC model (inherited from Nix) is brutally simple: if the raw string /gnu/store/xxx occurs anywhere within a protected /gnu/store/yyy (e.g. in a binary), then xxx is also protected, recursively.

Assuming those assumptions hold here it's a 'mystery' why git got GC'd.  From experience and for our collective peace of mind I'd say it's more likely that they didn't hold somehow, than that there's a serious GC bug :-)

> And I think that that is the different between regular inputs and propagated inputs, whether inputs become eligible for GC at run-time or not.

So, no.  Completely unrelated.  The GC has no concept of time at all.  This isn't Gentoo.

Propagated inputs are 'oh, here's this extra thing I was unable to properly patch, please add it to the profile and treat it as a GC reference anyway'.

This is ugly and regular, non-propagated inputs are always preferred.  Some software just makes them too painful.
Cees,

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Previous Next

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