GNU bug report logs - #55231
[PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Previous Next

Full log

View this message in rfc822 format

From: Morgan Arnold <morgan.arnold <at> proton.me>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Tobias Geerinckx-Rice <me <at> tobias.gr>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ian Eure <ian <at> retrospec.tv>, Mathieu Othacehe <othacehe <at> gnu.org>, Brian Cully <bjc <at> spork.org>, Leo Famulari <leo <at> famulari.name>, Andreas Enge <andreas <at> enge.fr>, Kaelyn <kaelyn.alexi <at> protonmail.com>, Felix Lechner <felix.lechner <at> lease-up.com>, John Kehayias <john.kehayias <at> protonmail.com>, Christopher Baines <guix <at> cbaines.net>, 55231 <at> debbugs.gnu.org, Simon Tournier <zimon.toutoune <at> gmail.com>
Subject: [bug#55231] [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’
Date: Sun, 16 Feb 2025 18:25:12 +0000

Hi Ludo,

I'll try to (hopefully accurately) summarise the discussion.

> Who would distribute it though? A build farm building a ZFS-enabled
> initrd, right? Is that a real use case? (Perhaps this has already been
> answered before; please let me know what I should look at, it’s a long
> discussion!)

As you note, the only person who would distribute such a pre-compiled initrd would be someone who built one and shared it, say with `guix publish`. A lot of the discussion essentially boils down to one question: is Guix responsible only for not committing copyright violations itself, say by not distributing such a pre-compiled initrd itself, or is Guix also responsible for putting in guardrails to prevent users from accidentally committing copyright violations? If you subscribe to the former view, then the original changes proposed by Brian are entirely acceptable as is. If, instead, you subscribe to the latter view, then this change may be unacceptable, as it facilitates the accidental commission of copyright violations by users of Guix. The changes made here to derivations are an attempt to allow users to create ZFS-compatible initrds in a manner which is compatible with the latter (more conservative, in some sense) view of the responsibilities of Guix.

> > + (let* ((substitutable-inputs? (every substitutable-derivation?
> > + (map derivation-input-derivation
> > + inputs)))
> 
> 
> This change doesn’t come for free. I didn’t follow the discussion, but
> adding overhead to such a core component to accommodate ZFS sounds
> questionable to me.

I agree that this is quite a lot of overhead. However, if one subscribes to the second view regarding the responsibilities of Guix, then some change like this seems to me to be required if we are to support Guix on ZFS at all. It might be possible to have the best of both worlds, by introducing a new parameter to the `derivation` function which controls whether or not `#:substitutable? #f` has this propagating behaviour. We could then restrict these large-overhead computations over entire dependency graphs to initrds only, which I think would reduce the overhead to an acceptable level. If the consensus is that we ought to be preventing users from accidentally committing copyright violations, and that the level of overhead introduced by this change is unacceptable, then I think that the way forward is by implementing this new parameter, say `#:propagating-substitutable?` or similar.

Best,

Morgan

Previous Next

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