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.
When I added myself as a maintainer here, I thought it would be way
less work than it turns out to be, because I didn't realise how
vulnerability-prone libtiff is. I basically haven't been maintaining
it at all, so let's reflect reality.
With the update to libtiff 4.6 in
0a74a54ac2 ,
many tiff-processing utility executables got dropped:
http://www.simplesystems.org/libtiff/releases/v4.6.0.html
Some of these executables can still be "restored" with
the configure switch `--enable-tools-unsupported`,
but unfortunatelly,
at least hylafaxplus (maybe more packages) relies on
utilities that even cannot be restored with this switch.
The commit at hand reintroduces the old libtiff
version 4.5.1 as `libtiff_4_5` into nixpkgs.
It restores the old build recipe with the following changes:
* passthru.updateScript is dropped as it is of no use here
* passthru.tests is dropped as it only contains
packages that now build with the new libtiff version
* patches are applied for the two CVEs that are fixed in 4.6.0
As libtiff 4.5 is no longer supported by libtiff developers,
new vulnerabilities will likely go unnoticed
unless they also affect the current version.
To not disable hydra builds, we don't add
`knownVulnerabilities` *for now*, but add comments to alert
updaters of the current libtiff version so patches can
be backported or the situation be reevaluated as a whole.
libGL is bloating the closure by depending on mesa.
0a678b4500 ('libtiff: Disable OpenGL entirely for Darwin')
b02908c213 ('libtiff: Reenable OpenGL support on Darwin')
On the Hydra builders and with Clang 7, CMake fails to find OpenGL. With
Clang 11 it manages to find the the OpenGL and GLUT system frameworks
for me. It does not find `gl.h` however. So the tests for `tiffgt` fail
on a missing include.
Since previously OpenGL wasn't detected I've opted to disable the CMake
check for OpenGL for darwin. This means `tiffgt.c` is never built and
tested. Ideally we'd provide the proper headers so the tests can
succeed.
The CMake implementation seems to be very in flux, and the latest
release broke cross-compilation for us. Autotools seems to be
upstream's recommended build system -- it's the one mentioned in the
README.
Now that libtiff is using cmake, we need to let cmake
set the build rpath for the tests to pass on darwin.
The rpaths are rewritten at installation so
the output libraries should be unaffected.
