guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#55231] [PATCH v3 2/2] doc: ‘initrd-modules’ will search ‘kernel-loa


From: Maxime Devos
Subject: [bug#55231] [PATCH v3 2/2] doc: ‘initrd-modules’ will search ‘kernel-loadable-modules’.
Date: Sat, 18 Jun 2022 22:34:53 +0200
User-agent: Evolution 3.38.3-1

Brian Cully via Guix-patches via schreef op za 18-06-2022 om 15:11 [-
0400]:
> +If a module listed in @code{initrd-modules} is not included in the
> +Linux-libre kernel, then the location to it must be added to the
> +@code{kernel-loadable-modules} list.  For example, if your root file
> +system exists on a ZFS pool, then your configuration might look like the
> +following:
> +
> +@lisp
> +(operating-system
> +  ;; @dots{}
> +  (initrd-modules (cons "zfs" %base-initrd-modules))
> +  (kernel-loadable-modules (list (list zfs "module"))))
> +@end lisp

As written previously, this is not a good example, because:

> As-is, I don't think this is a good example, because
> 'expression->initrd' does not set #:substitutable? #false,
> the 'zfs' package has the comment (*)
> 
>      `(;; The ZFS kernel module should not be downloaded since the
> license
>        ;; terms don't allow for distributing it, only building it
> locally.
>        #:substitutable? #f [...])
> 
> and IIUC, the code inside expression->initrd copies the kernel module
> into the new store item, so it looks like this accidentally suggest
> people to commit copyvios, and copyvios are currently against the
> law.

and because the defense for not considering the ZFS license to be a
problem consists of the ZFS module not being distributed in binary
form, whereas this suggestion would in some situations cause it to be
distributed in binary form.

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]