short-term plans for libtiff

[Jay Berkenbilt <qjb@debian.org>]

I'm planning on a new upload of tiff where all existing packages are
unchanged and there's a new package called libtiff5-alt-dev.  This
package installed the tiff 4.x headers and libraries in a path that does
not conflict with libtiff4-dev, and it installs the libtiff pkg-config
files in the usual location.  (libtiff4-dev does not provide
pkg-config.)  libtiff5-alt-dev conflicts with libtiff5-dev (since they
both install pkg-config files) but not with libtiff4-dev.  It is
possible to have both libtiff5-alt-dev and libtiff4-dev installed at the
same time, and this makes it possible to build a package that directly
requires libtiff5 and indirectly depends on libtiff4-dev, such as vips.
This will work easily for packages that use pkg-config to find tiff
headers.  A few packages do this and then fall back to standard system
paths if pkg-config fails.  Those packages work with either libtiff4-dev
or libtiff5-dev.  For packages that declare build dependencies on
libtiff5-alt-dev and use pkg-config to find tiff, all they have to do
after the transition is change the build dependency to libtiff-dev.

Can you think of any reason that this could possibly cause any harm?  I
don't think it will since it won't have any impact at all on packages
that don't explicitly build depend on libtiff5-alt-dev.  I'm going to go
ahead and do the upload.  If it's a bad idea for some reason that I am
failing to see, it can always be rejected from NEW.

If this is a bad idea for some reason, I would really like to find a
solution so that vips and nip2 (among others) can have bigtiff support
before wheezy.

-- 
Jay Berkenbilt <qjb@debian.org>