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.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
