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
