As the comment says, this should only have happened on Linux, not all
non-Darwin platforms.
Fixes pkgsCross.x86_64-netbsd.fzf.
Fixes: 1693ed2be9 ("fzf: wrap 'perl' in scripts with LOCALE_ARCHIVE")
It was previously referencing `$bin`, but this package no longer produces a
`bin` output, just `out` and `share`. Updated to make the comparison check a bit
more robust.
Also updated to avoid direct dependency on the `$src` directory out of the nix
store, instead using the processed src setup in the unpackPhase. This provides a
cleaner abstraction between the build/install phase and the input src phase, and
avoids an unnecessary dependency on whether the source disted tarball comes from
`fetchFromGitHub` (in which case it's an unpacked directory) or something like
`fetchurl`. In either case, stdenv is responsible for processing the input `src`
and setting up a clean build dir for us, so we should use that.
This produces an equivalent directory tree, except that the vim plugin is no
longer broken.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
