Understanding #:substitutable? and #55231

[Morgan Arnold]

Hello,

I have been working on trying to set up a booting ZFS-based system with Guix, 
and am trying to understand the reasons that #55231 (which would help greatly 
with this, as Kaelyn noted last May) was not merged. Of course, it may simply 
be lack of reviewer time, which is fine. It did, however, seem that there was 
some concern expressed regarding the `#:substitutable` flag, and the 
possibility of redistributing a compiled ZFS kernel module as part of an initrd.

My understanding of the issue is that when an initrd is created using the 
`expression->initrd` function, a call to `computed-file` is made, and the 
options which are ultimately passed to `gexp->derivation` do not include 
`#:substitutable? #f`, so a situation is created where, in principle, a 
compiled ZFS kernel module could be distributed. The concern expressed seemed 
to be generally one of documentation, in which case I think that the fact that 
the documentation was changed not to use a non-substitutable module as an 
example should cover any opposition to the merging of #55231.

If the concern is rather that this change makes it easier for someone to 
accidentally redistribute a compiled ZFS kernel module and commit a copyviol, I 
struggle to see how this concern is particular enough to #55231 to be a reason 
not to merge it. It seems to me, at least in principle, that it would be just 
as simple to commit a copyviol by using, say, the `make-linux-libre` function 
(which does not appear to set `#:substitutable? #f` on the resulting 
derivation, unsurprisingly) to build a kernel with the ZFS kernel module built 
in, and then redistributing that. It seems like the only way to completely 
remove this possibility would be to make `#:substitutable?` "poisoning", so to 
speak, in the sense that any derivation taking non-substitutable derivations as 
inputs would be marked non-substitutable itself. This seems to entirely 
eliminate the possibility of substituting something which is non-substitutable, 
but I have no idea if this is practical or even desirable.

If the issue is simply that the patch has not been rebased against a new enough 
version of Guix to be merged, I am happy to do that rebasing. Additionally, 
please correct me if I have made any incorrect assertions above.

Best,

Morgan