I've gone ahead and rebased the patches. I'm not sure what the appropriate way to get attention for an old issue is, but hopefully someone comes across it on the patches mailing list and reviews it, I suppose.
Best, Morgan -------- Original Message -------- On Feb 5, 2025, 18:02, Morgan Arnold via "Development of GNU Guix and the GNU System distribution." wrote: > 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
