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

From: Maxim Cournoyer <[email-masked]>
Date: Mon, 17 Feb 2025 11:26:47 +0900

Hi Ludo,

Ludovic Courtès <[email-masked]> writes:

[...]

>> +    (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've measured with strace -fc and time, and the difference appeared
negligible.

>> +          ;; DRV2 is *not* available as a substitute, since it has drv1 as
>> +          ;; input, and the non-substitutability is viral to avoid
>> +          ;; distributing non-substitutable items that could have become
>> +          ;; embedded, for example in an initrd.
>
> 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!)

It's that far fetch that substitute servers like berlin or third party
ones could want to use ZFS RAID 5/6 themselves to minimize disk usage
while having some redundancy, so yes, that's the most likely use case, I
think.

Then a downstream user of such build farm/substitute server could use
ZFS themselves and find themselves fetching ready-built initrd's binary
containing the ZFS module, which should not be happening due to the
license incompatibility between ZFS's CDDL and the Linux kernel GPL2
only.

-- 
Thanks,
Maxim