[bug#45692,0/4] Even Better ZFS Support on Guix

Hi all,

Sorry for the excessive number of patches.

This patchset contains 4 patches, two that add new features to Guix and do not involve ZFS at all, one bugfix of the ZFS package, and one which makes installing ZFS on Guix easy.

* Patch 1: Create an extensible service type that installs kernel-loadable modules into the kernel.
  * This allows a ZFS service to add the ZFS module to the kernel.
* Patch 2: Make the `file-systems` shepherd service an extensible target, so that other services can add more requirements for `file-systems`.
  * This allows a ZFS service to make `file-systems` wait for the ZFS automount at startup, which is necessary in any case in order to ensure that ZFS has scanned for ZFS pools installed in the hardware.
* Patch 3: Fix the ZFS package definition.
* Patch 4: Add a ZFS service type that installs everything needed for basic ZFS usage!

I've tested the ZFS functionality in about a half-dozen VMs already, including checking that the ZFS setup persists across reboots of the VM:

* No ZFS installed.
* With ZFS installed but without any ZFS pools.
* With ZFS pool that is automounted.
* With ZFS pool in legacy mode (needs manual `mount -t zfs poolname /mountpoint`).
* Encrypted ZFS dataset (prompts passphrase at boot to mount).
* Encrypted ZFS dataseet as `/home` (prompts passphrase at boot to mount, user `/home` directories are created and maintained).

Other bits of ZFS functionality would be *nice* but aren't in this patchset yet (and at least for my purposes are not really necessary, except perhaps the auto-scrubbing, I just need to wrap my head around `mcron`...):

* Auto-scrubbing of ZFS pools to ensure no data corruption.
* Auto-snapshotting of ZFS datasets to protect against user error.
* `/` on ZFS.
* `/boot` on ZFS.
* Managing ZFS "legacy" mountpoints on  `(file-system ...)` declarations.
* Managing ZFS pool setup in the `operating-system` declaration somehow (not sure how to do this).

Thanks
raid5atemyhomework

Thanks a lot for the patches!

On Mon, 2021-03-22 at 14:33 +0000, raid5atemyhomework via Guix-patches
via wrote:
> Personally I'm not particularly motivated to push this anymore.  I
> have a frankenstein's `configuration.scm` that gets me the bits of
> ZFS functionality that I absolutely need, with the rest something I'm
> just living without, and while it would be *nice* to have *some* out-
> of-the-box support for ZFS (or at least make it easy to get a box to
> get support for ZFS out of), I personally don't need it at this
> point.

I understand your frustration but also understand that the people who
are able to review your patches can't make themselves available in the
way you desire, there's lots of pending patches to GNU Guix and as much
as ZFS support is valuable, there's also lots of other things that are
valuable and are in the backlog.

> Patch 1/3 corresponds to the original Patch 1/4.  Patch 2/3 has no
> corresponding patch in the original patch set, but is the same patch
> as https://issues.guix.gnu.org/47134 which nobody is looking at, as
> usual.  Patch 3/3 corresponds to the original Patch 4/4.

Please do not blame or shame us for not looking at patches, it's not
very nice, we do our best, at all times. We are overworked and the
people who are knowledgeable about GNU Guix and Scheme particularily
so. I don't feel like I am knowledgeable about Scheme and GNU Guix
enough to review your patches, sorry for that.

Léo

> On Mon, 2021-03-22 at 14:33 +0000, raid5atemyhomework via Guix-patches
> via wrote:
>
> > Personally I'm not particularly motivated to push this anymore. I
> > have a frankenstein's `configuration.scm` that gets me the bits of
> > ZFS functionality that I absolutely need, with the rest something I'm
> > just living without, and while it would be nice to have some out-
> > of-the-box support for ZFS (or at least make it easy to get a box to
> > get support for ZFS out of), I personally don't need it at this
> > point.
>
> I understand your frustration but also understand that the people who
> are able to review your patches can't make themselves available in the
> way you desire, there's lots of pending patches to GNU Guix and as much
> as ZFS support is valuable, there's also lots of other things that are
> valuable and are in the backlog.
>
> > Patch 1/3 corresponds to the original Patch 1/4. Patch 2/3 has no
> > corresponding patch in the original patch set, but is the same patch
> > as https://issues.guix.gnu.org/47134 which nobody is looking at, as
> > usual. Patch 3/3 corresponds to the original Patch 4/4.
>
> Please do not blame or shame us for not looking at patches, it's not
> very nice, we do our best, at all times. We are overworked and the
> people who are knowledgeable about GNU Guix and Scheme particularily
> so. I don't feel like I am knowledgeable about Scheme and GNU Guix
> enough to review your patches, sorry for that.

Okay.

Thanks
raid5atemyhomework

Can I get any particular feedback here at this point, from anyone at all?

Maxime writes,
  
    > The GPL violation is very unfortunate. It would have been nice to
    > have some ZFS support in Guix.

There is no GPL violation. Gaslighting in an attempt to sabotage the
adoption of high-quality free software is somewhat poor form and not at all
useful.

To be clear, the one singular thing that would be a GPL violation would be
Guix building Linux with ZFS built in and then distributing that binary.
Users can build ZFS into their kernels and use them and that's fine as long
as they don't distribute them. Guix can script this to make it easy for
users to build ZFS into their kernels and that would not be a violation.
The only possible violation is distribution of a binary Linux kernel with
ZFS compiled into it.

Hope that helps.

Mason Loring Bliss schreef op do 02-09-2021 om 17:24 [-0400]:
> Maxime writes,
>   
>     > The GPL violation is very unfortunate. It would have been nice to
>     > have some ZFS support in Guix.
> 
> There is no GPL violation. Gaslighting in an attempt to sabotage the
> adoption of high-quality free software is somewhat poor form and not at all
> useful.

Indeed, gaslighing is poor form and not at all useful.  But why are you suggesting
I'm gaslightling here?  Did you just read these last two sentences of the e-mail?
If you read all of it, you'd have seen my explanation of why I believe there's
a GPL violation, and two relevant links to articles by SFLC and FSF. 

Also see IRC logs:
https://logs.guix.gnu.org/guix/2021-09-02.log
https://logs.guix.gnu.org/guix/2021-09-03.log

While ultimately it's a matter for the courts to decide on,
I believe I've reasonable grounds to believe it's a GPL violation
and explained why, so I don't see any gaslightling here.

And I'm not ‘sabotaging’ anything.  In fact, I'm _helping_ adoption of ZFS,
by reviewing the patch and giving some suggestions.  There is just the practical
problem of the in-my-eyes probable GPL violation (your opinion on whether it's
a GPL violation might vary).

> To be clear, the one singular thing that would be a GPL violation would be
> Guix building Linux with ZFS built in and then distributing that binary.
> Users can build ZFS into their kernels and use them and that's fine as long
> as they don't distribute them. Guix can script this to make it easy for
> users to build ZFS into their kernels and that would not be a violation.
> The only possible violation is distribution of a binary Linux kernel with
> ZFS compiled into it.

See the previous mail and the IRC logs for why I find this reasoning rather
flimsy.

> Hope that helps.

No, your libel about ‘Maxime is gaslighting’ doesn't help.  And your paragraph
about why you think there's no GPL violation here is nothing I haven't read before.

I probably won't be reading and replying to your mails anymore.

Bye,
Maxime

Hi Mason,

On Thu, 02 Sep 2021 at 17:24, Mason Loring Bliss <mason@blisses.org> wrote:

>                            Gaslighting in an attempt to sabotage the
> adoption of high-quality free software is somewhat poor form and not at all
> useful.

Using such language (emphasized by the subject), you are not creating a
positive environment.  Please be respectful when differing viewpoints
and experiences.  And please assume good faith avoiding to jump in
negative opinionated conclusions.

Thanks,
simon

Happy birthday 45692!

BUMP

close 45692
quit

No point: nobody will review or merge anyway.