Bug#558733:

[Francesco P. Lovergine]

On Mon, Sep 05, 2011 at 12:47:29PM +0200, Johan Van de Wauw wrote:
> On Mon, Sep 5, 2011 at 10:46 AM, Francesco P. Lovergine
> <frankie at debian.org> wrote:
> 
> > Yep, I will introduce versioning in the incoming 1.8 series to solve
> > this problem. Unfortunately this will also break binary compatibility
> > with third-parties programs not built against Debian Gdal. So I will
> > also expect a few complains about that... :-/
> 
> I understand that -merely by the number and importance of packages
> affected- the libtiff transition is not going to happen soon.
> But I still wonder what's blocking the release of libtiff 4.0 (and
> libtiff5 for unstable). Or to put things differently: why do we (and
> the gdal maintainers) consider libtiff5 stable enough for gdal, if it
> is not yet released*? We could also choose to use the system version
> and live without bigtiff support, it's a different way of solving this
> bug.
> 

The in-development-forever status of 64bit TIFF library since ages
makes me think that the issue will not be solved anytime soon.

It is not a technical problem, I really do not understand why it
is still consider not ready (and who is responsable of releasing indeed
at this time). 
For sure, for most use of TIFF, the old 32 bit API is stable and 
usable enough and that motivates perhaps the current laziness. 
This is not the same for the GIS area, where we are 
lacking a decent free lossy compressed format for very large images.
Removing bigtiff is a non-go, and I prefer introducing versioning
to solve the problem.

-- 
Francesco P. Lovergine