Using `with` in such a high up scope makes it very easy to
accidentally forget to update function arguments and introduce typos
because of the lack of any editor support and static analysis.
It's better to explicitly inherit the small number of things we need
from `lib` into scope so that editors can know of scoped variables.
Fix the following error when running `nix run .#zfs`:
error: unable to execute '/nix/store/ns6rifm17r0lp17w8gb4qr5db4cwbkj9-zfs-user-2.1.1/bin/zfs-user': No such file or directory
We cannot have trace output if the package is marked broken, because
ofborg will consider the evaluation failed if there is any output. Hence
if there is any unsupported kernel version in nixpkgs, the trace will
show up and ofborg will complain.
In https://github.com/openzfs/zfs/commit/658fb802 OpenZFS introduced a
new compatibility feature. This is accompanied by some default profiles
which are located in the $out output of the Nix derivation. However,
these compatibility profiles are used by both the zpool executable
located in $out and the libzfs library located in $lib. This
inadvertently creates a cycle, because zpool refers to $lib to link
against libzfs but libzfs refers back to $out for the compatibility
profiles.
There are two possible routes to rectify this problem:
1. Patch the zpool source code to not read the compatibility profiles
and adjust the build system to put them into the $lib output.
2. Simply remove the $out/$lib split.
Since no other derivation in nixpkgs refers to the $lib output
explicitly we opt for the latter, because this is also in accordance
with upstream.
`throw` aborts eval when the package is touched in inappropriate places. See
https://github.com/NixOS/nixpkgs/issues/109001 for an adverse instance of that.
ZFS now behaves like a regular broken package when it's, you know, broken.
It also still prints the helpful incompatibility notice when fully evaluated.
