On 9/02/2025 2:06, Ian Eure wrote:
Hi Morgan,
Morgan Arnold via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> 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
