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

[raid5atemyhomework]

> 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