[bug#45403] [PATCH] gnu: zfs: Split into packages specific for each of our major supported kernel versions.

[raid5atemyhomework via Guix-patches via <guix-patches@gnu.org>]

> Here's another alternative:
>
> -   Remove the separate "module" output and put the `.ko` file in the "out" output.
> -   Create a separate `zfs-guix-tools` which provides `zpool`, `zfs`, `zed`, `arc_summary`, `arcstat`, `dbufstat`, `raidz_test`, `zgenhostid`, `zvol_wait`, `fsck.zfs`, `mount.zfs`, `zdb`, `zhack`, `zinject`, `zstreamdump`, `ztest`.
>     -   What the provided binaries do is:
>         -   It looks at `/run/booted-system/kernel/manifest` and looks for a `"zfs"` package.
>         -   It `exec`s into the corresponding file in the `/gnu/store` for that package.
>
>             This way, we can have a separate package for ZFS userspace tools, which just calls the corresponding tools in the actual ZFS that gets installed.
>             It's somewhat magical, though.
>

Unfortunately, this confounds `bash-completion`.  We want the bash-completion from the actual compiled ZFS, not the shim `zfs-guix-tools`.  We could try digging for it too in the `kernel/manifest`, but that just adds more complexity and maintenance headaches.

It's also an extra layer of complexity and maintenance burden to create this shim wrapper that digs through your kernel manifest to look for the userland tools you need to manage ZFS in the same package that contains the actual ZFS kernel module.  I think it's better to just expose a `make-zfs-package` that overrides the `#:linux` and creates a new package that you can install in `(packages ...)` **and** in `(kernel-loadable-modules ...)`.

See https://issues.guix.gnu.org/45643 for my current latest patchset.

Thanks
raid5atemyhomework