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

From: Ludovic Courtès <[email-masked]>
Date: Mon, 17 Feb 2025 11:00:14 +0100

Hi,

Maxim Cournoyer <[email-masked]> skribis:

> 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.

Not sure if that’s what you did, but I would time ‘guix build
libreoffice --no-grafts -d’ or something along these lines.

>> 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.

Yes, I understand.  But my point is, in practice, our build farms are
not going to publish such binaries.  So really the use case is a
hypothetical build farm (or user running ‘guix publish --advertise’) who
happens to have a local ZFS+Linux build.  It’s possible, but it’s
arguably pretty niche.

The cost/benefit ratio doesn’t look great to me.

Ludo’.