2012.01.22 16:53 "[Tiff] update on tiff 4.x in debian", by Jay Berkenbilt

2012.01.22 16:53 "[Tiff] update on tiff 4.x in debian", by Jay Berkenbilt

In case anyone's interested in the status of tiff 4.x in debian, I'll provide an update. Based on lessons learned with similar transitions to the png and jpeg libraries, it basically isn't going to happen unless the tiff library versions its symbols. Without symbol versioning in the shared library, there's no way for an application to simultaneously use both the old and the new version of the tiff library, and through indirect use, this will happen all the time. (Application A links with lib1 and lib2, lib1 links with tiff 3.x, lib2 links with tiff 4.x.) The jpeg and png libraries both added versioned symbols, and the tiff library will have to do the same. While I surely have the skills to do this, I don't know off hand how to do it, and my time is very limited. I will probably eventually get to it unless someone beats me to it. Anyway, I'm posting here in case anyone is interested in tackling this. The jpeg and png libraries would be good places to start. Having spent about 10 minutes studying this problem, I think the way the jpeg library does it is easier: it basically versions every public symbol rather than explicit managing what is public and what isn't. The png way is probably technically stronger, but it would take much more time to get right.

Anyway, if someone knows a good way to do this and wants to jump in, now would be a great time. Otherwise, I'll try to see if I can get it to work. The ultimate test would be to create the scenario I described: an application that uses tiff indirectly through two different shared libraries, each of links with a different version.

After this is done, then debian can have both tiff 3.9.x and tiff 4.x in the archive at the same time, which means that supporting the newer tiff version will not put us at the mercy of everyone who uses the tiff library upgrading at the same time.

--Jay