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

From: Maxime Devos <[email-masked]>
Date: Sun, 9 Feb 2025 18:11:33 +0100

On 9/02/2025 2:06, Ian Eure wrote:

> Hi Morgan,
>
> Morgan Arnold via "Development of GNU Guix and the GNU System 
> distribution." <[email-masked]> writes:
>
>> Hello,
>>
>> 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.

No. See the stuff about #:substitutable?. The reason I didn't answer 
back then, is that I don't want to keep being a broken record.

If 'make-linux-libre' in the presence of ZFS leads to #:subsitutable? 
problems, that doesn't mean it's fine to ignore the law for #52231. It 
means you need to:

  (a) remove ZFS
  (b) or adjust 'make-linux-libre' (whether code or documentation, 
preferably code) to do the #:substitutable? thing

More generally, legality > convenience (except in case of revolution, 
but that's not applicable to Guix, and it seems inadvisable to talk 
about such matters in the open).

More specifically, ZFS proponents (at least as a group, and when limited 
to those visible in Guix) tend to be rather incoherent in their 
positions, in the sense that simultaneously do:

  (1) consider GPL and ZFS license to be compatible,
  (2) with caveat about "no binary distributions"  (legal restriction)
  (3) want to get ZFS in a distribution
  (4) their method to get ZFS in the distribution doesn't address point (2)
  (5) and they refuse to fix the legal issue (4) when pointed out to 
them, with as reason:
  (5a) previous versions of Guix already violate restriction (2)
  (5b) it's technically slightly inconvenient

Like, (5a) just makes things _worse_ (as now would be _knowingly_  in 
violation of the law, and the duration of the violation increases) and 
(5b) is utterly irrelevant to the law - Guix is subject to the law, not 
the other way around.

And pointing this out to them doesn't seem to ever work.

It has been some time ago, but I probably suspected it wouldn't work in 
this case either.

> It does seem that #55231 ended up in a place where there was concensus 
> that it was acceptable, but didn’t get merged for some reason or 
> other.  I definitely could be wrong, but I suspect the issue is that 
> when non-#:substitutable? packages are used in places other than 
> package inputs, the downstream derivations don’t carry that 
> information.  I believe when used as a package input, 
> non-#:substitutable? packages do, in fact, poison all downstream 
> derivations.  Happy to be corrected if I’m wrong here.

Not quite - to my understanding, the downstream derivations _also_ don't 
carry that information when it's in package inputs (at least, last time 
I checked there didn't seem to be any mechanism to set #:substitutable? 
to #false when any of the inputs are unsubstitutable (whether non-bag(?) 
derivation inputs, implicit inputs, native-inputs, ...)).

For packages, in typical situations the #:substitutable? #false of any 
'native-inputs' of a package shouldn't impact the substitutability of 
the package. For 'inputs', it rather depends (e.g. static/dynamic, the 
particulars of the license, is it because of license reasons or 
something else). Since it somewhat depends on the situation, if you 
implement a thing like this, I would recommend making it a _default_ for 
#:substitutable?(*), that can be overridden by some method.

> I think it’s reasonable to merge this after it’s rebased on current 
> master, and would be willing to do that unless Maxime or Ludo’ raise 
> an objection.

First you say you suspect the issue is that #:substitutable?-related 
behaviour isn't right yet, and immediately in the next paragraph you say 
it's reasonable to merge it. Given that the patches haven't been 
adjusted to solve this, this is rather incongruent.

I already raised the objection several times in the past (including 
_before_ #55231), and none of the patch revisions attempted to deal with 
the objection.  Issues don't simply magically resolve themselves. I 
believe you can infer whether I would object to the current state of 
#55231 or not.

Regards,
Maxime Devos