[I'm not subscribed to debian-devel at the moment, so please cc me on responses in the unlikely event that there need to be any.]
I've uploaded new versions of libtiff4-dev and libtiff-dev (now the name for libtiff5-dev, with libtiff5-dev as a virtual package). libtiff-dev now provides both libtiff4-dev and libtiff5-dev, and libtiff4-dev provides libtiff-dev. The consequence of this change is that packages that depend on libtiff-dev will not get libtiff5-dev (which is what we want) and packages that depend on libtiff5-dev or libtiff-dev can build depend on other packages that themselves depend on libtiff4-dev. This makes it possible for people who want bigtiff support to immediately change their build dependencies to libtiff-dev (>> 4.0.1-6~). That version also includes pkg-config support. If you're already using libtiff5-dev as a build dependency, there's no need to change it, but if you want to switch to libtiff-dev at your next upload, that would be reasonable. Technically, it's not 100% correct for libtiff-dev to provide libtiff4-dev because there are a very few source-incompatible changes. However, all the changes are in parts of the interface that are deprecated or not used by normal applications. My spot check of a handful of high-profile or complex packages has not revealed any trouble, and I didn't have to change any of my own code to switch from tiff4 to tiff5. Lots of applications can support both, and many have been supporting both for some time. If you run into compile errors, you can either explicitly build depend on libtiff4-dev and nag your upstream, or you can fix them yourselves based on the information here: http://libtiff.maptools.org/v4.0.0.html -- Jay Berkenbilt <q...@debian.org> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513103548.0386547332.qww314159@soup
