Subject: Re: Understanding #:substitutable? and #55231

From: Morgan Arnold <[email-masked]>
Date: Mon, 10 Feb 2025 15:53:54 +0000

Hi Andreas,

Thanks for the clarification. If this is the case, and texlive is unlikely to be used as a native input, it seems reasonable to me that setting `allowSubstitutes = 0` if `(not (and substitutable? (every substitutable-derivation? inputs)))` would entirely eliminate the possibility of ZFS-based copyviols, as any derivation depending on it could not be substituted, and so neither Guix nor anyone using Guix could commit a copyviol. A user who wishes to use ZFS will then download the source code, compile the kernel module, and include it in their initrd, and this initrd will not accidentally be distributed. To the best of my non-lawyer understanding, this would not constitute any kind of copyviol.

This seems to me to implement a maximally conservative (in terms of avoiding possible copyviols) approach to incorporating ZFS into Guix. If this makes sense, I would be happy to include that change to `derivation` in this patch set.

Best,

Morgan

On Monday, February 10th, 2025 at 14:42, Andreas Enge <[email-masked]> wrote:

> 
> 
> Hello,
> 
> Am Sun, Feb 09, 2025 at 10:42:26PM +0000 schrieb Morgan Arnold via Development of GNU Guix and the GNU System distribution.:
> 
> > It might be more correct to allow derivations built with non-substitutable native inputs to be substitutable nonetheless. The alternative seems like it could cause issues, in particular with the non-substitutable texlive package being used as a native input to build documentation.
> 
> 
> just to clarify, texlive (or more precisely, texlivetexmf) is marked as
> non substitutable not because it would not be allowed, but because it is
> huge and essentially just an unpacked big tarball. So people had better
> build the package by themselves.
> 
> And it should not be used as a (native-)input to other packages: We have
> the much smaller modular texlive packages for this, which make it
> possible to depend precisely on what is needed to build the
> documentation.
> 
> Andreas