This reverts commit f57a4b0ac1.
The old version libtiff_4_5 is no longer needed.
Both dependents (gscan2pdf and hylafaxplus)
have switched to the forked libtiff version 4.6.0t
which is based on the current libtiff version 4.6.0
but also contains required command line tools
missing in the original libtiff library.
libtiff 4.6.0 dropped a bunch of helper tools,
thereby breaking packages that depend on these tools.
To fix those packages, nixpkgs started packaging libtiff_4_5
separately, see commit f57a4b0ac1.
Currently, two packages use libtiff_4_5:
* hylafaplus (cd3771c709)
* gscan2pdf (9a579e14dd)
Lee Howard (core developer of hylafaxplus)
forked libtiff 4.6.0 to provide a current version
that restores those dropped helper tools.
The library is also called "libtiff",
with current version "4.6.0t".
It is based on libtiff 4.6.0 and incorporates several fixes,
particularly for the dropped helper tools,
see https://sourceforge.net/p/hylafax/mailman/message/58751878/
and http://www.libtiff.org/releases/v4.6.0t.html .
The commit at hand packages that fork for nixpkgs.
Follow-up commits will replace libtiff_4_5 with
libtiff_t, so affected packages can
again use a current libtiff library.
The build recipe of libtiff_t is based on the libtiff recipe.
Besides adapted URLs, the only change is dropping `passthru`, as
it referred to many packages depending on the original libtiff.
The unorthodox code introduced in all-packages.nix
is needed to satisfy the automated "by-name" check;
see "Recommendation for new packages with multiple versions"
in the file `pkgs/by-name/README.md`.
Depending on how things develop in the future,
we might want to switch completely
to the forked libtiff library one day.
Or the original libtiff restores the missing tools,
making libtiff_t superfluous.
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
To reduce dependencies (mainly nix-prefetch-git and through that git,
git-lfs) when we just need to fixup a lock file, eg when building electron.
This also tries to avoid needless rebuilds when eg. golang is updated.
Also this cleans up and combined the build/installPhase of both tools to
be a lot simpler.
