2012.02.04 21:28 "Re: [Tiff] ready for 3.9.6 and 4.0.1", by Jay Berkenbilt

On 02/04/2012 02:15 PM, Lee Howard wrote:

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.

It's all so clear now! ;-)

(But seriously, I have the most impossible time figuring out Debian versioning. Every time I have the privilege to install or work on a Debian system I spend way too long trying to figure out if I should be apt-get installing "libtiff", "libtiff4", "tiff", or some other unknown.)

It is confusing, and the fact that the tiff3 source package provides libtiff4 and the tiff source package provides libtiff5 will cause no end of confusion. There is a method to the madness though. The runtime library's package name always includes the soname of the shared library, so libtiff.so.5.whatever would be provided by a package called libtiff5. This is important because the library can be upgraded without changing executables or libraries that were linked with it, and the soname doesn't have to (and shouldn't) track with the version of the software package. If the shared library package were to track with the version of the software, automatic upgrades would be much more complicated in the ordinary case of binary compatible updates. For example, the vips libraries, which I also maintain, have been called libvips15 for many versions because they are very careful not to break binary compatibility with new updates.

So that pretty much determines the name of the package that provides the runtime library. For the development library, the custom is to do one of two things: either stick -dev on the end of the runtime library package, or have a numberless dev package. The numberless pattern, which would be libtiff-dev, would be appropriate if there were never expected to be more than one version of the library in the archive at a time. This would be the case with most libraries that have only a few users where a non-compatible upgrade could be a full transition that everyone would take at the same time. The vips package I sited earlier is like this: its dev package is libvips-dev. The only package in debian that depends on it is nip2, and if there were a non-compatible change to libvips, we could just update libvips and nip2 at the same time. For packages like tiff, jpeg, png, and other libraries that have lots of reverse dependencies and may exist at more than one version at a time, a numbered -dev library is more practical, hence libtiff4-dev and libtiff5-dev, which exist at the same time. Most users, however, will not care about this detail and just want one version, so the pseudopackage libtiff-dev exists and "points to" the version that is the one you should be using if you don't know or don't care. For the moment, this is libtiff4-dev, but it will eventually be libtiff5-dev. I did the same stunt with the xerces-c libraries: libxerces-c2-dev is for the xerces 2.x series, libxerces-c3-dev is for the xerces-3.x series, and libxerces-c-dev is currently an alias for libxerces-c3-dev, the version people should be using by default.

Finally, to help clarify things for users a little more, I have mentioned in the description of the libtiff4-dev package that these are packages for the older 3.x version of tiff, and all the short descriptions for the packages provided by the tiff3 source package have the string "(old version)" in them.

As for why I called the source package tiff3 for the old version rather than, say, tiff4, it's because the intention is ultimately for there to be only one version in the archive at once, and that version is in the tiff source package. End users, and even developers who need the -dev libraries, don't have to care about the name of the source package. One could argue that I should have called the source package tiff4, but I didn't. Anyway, the source package comes with a version, so you currently have tiff3_3.9.5 and tiff4_4.0.0, which should make it pretty clear.

I hope this explanation is useful. While not all packages work this way, understanding this background should probably enable you to make more sense of the way library and dev packages are named in debian.

--Jay