2012.02.04 15:52 "[Tiff] ready for 3.9.6 and 4.0.1", by Jay Berkenbilt

2012.02.04 15:52 "[Tiff] ready for 3.9.6 and 4.0.1", by Jay Berkenbilt

I've done all the testing and experimental uploads I need to for debian, so whenever you're ready, you can go ahead and release 3.9.6 and 4.0.1 with versioned symbols. Once those are released, I will upload to debian unstable. What I've ultimately decided to do is to go ahead and make the "tiff" package based on tiff-4.0.1, but the "libtiff-dev" virtual package will remain only on libtiff4-dev, which will now be in the tiff3 source package. So the tiff3 source package will include binary packages libtiff4, libtiff4-dev and libtiffxx0c2 only, and the libtiff4-dev will "Provide" libtiff-dev. Anyone who has a current build dependency on libtiff-dev or libtiff4-dev (which is anyone in debian who depends on tiff in any way right now) will continue to build against 3.9 for now. The tiff source package will include libtiff5, libtiffxx5, libtiff5-dev, libtiff-tools, libtiff-opengl, and libtiff-doc, so all the tiff tools and so forth will be based on 4.0.1. The libtiff5-dev package will not "Provide" libtiff-dev, so no one who links against tiff will get the new version by default yet, but those who explicitly want or need to use tiff 4.x can explicitly build-depend on libtiff5-dev. Once the uploads are done, the release team will force a rebuild of the whole dependency chain so that all executables and shared libraries are linked with the symbol-versioned version of libtiff4. Since everything will have versioned symbols enabled, this will work seamlessly without disrupting anything currently in the archive.

Sometime right after wheezy is released, I will plan on trying to get tiff3 removed from debian. To facilitate this, I will remove the libtiff-dev virtual package from libtiff4-dev and put it on libtiff5-dev. Anyone who depends just on libtiff-dev should just rebuild and be fine. Some may have to patch for API changes, but it won't be hard since the changes are small. (Hopefully upstreams will start doing this anyway by then.) For packages that depend on libtiff4-dev, I will post bugs asking them to change to libtiff-dev so they'll always track with the default version in the archive. Once enough packages have moved over, I will request removal of tiff3, and that will force the rest to switch. Then wheezy+1 should release with only tiff 4.x. It will obviously be quite a long time before we can forget about 3.9.x since it's still hanging around in security-supported versions of debian until 1 year after wheezy+1 releases, not to mention other distributions that will still have the older version. But at least people who want or need tiff 4.x will be able to get it right away.

Users will inevitably get confused about the fact that libtiff4 is part of tiff3 and is from tiff 3.x and libtiff5 is part of tiff and is from tiff-4.x, but they'll get over it. Actually, most people won't need to know or care about this. Even casual users of the tiff library who don't care which version they use can just use libtiff-dev and not think about it. It's a non-concern, but when people seem confused, it's a good idea to make sure they're not assuming they're using a different version from what they are actually using.

I'm doing final uploads now to experimental with all the final package renames. Once this clears and the new "upstream" releases are out, I'll pull the trigger and debian will have tiff 4.0.1 in unstable.

--Jay