I guess I should’ve actually reported the lintian bug rather than just ignoring the bogus warning.

• 532 depend on zlib1g 1:1.2.3.3.dfsg-1, the version which introduced support for _FILE_OFFSET_BITS=64 and the version which packages that were built before zlib1g had symbol version information will depend on.
• 333 depend on version 1:1.2.1, which predates sarge let alone etch.
• 74 depend on the even earlier version 1:1.1.4-1.
• 843 packages have an unversioned dependency on zlib1g – a quick glance at some of these indicates that (as I would expect) they either don’t actually link against zlib directly or do but don’t use any symbols from it.
• The remaining two packages are the -dev and -dbg packages which have an exact dependency on the library package they were built against.

Of course, zlib is a particularly good use case for this – both API and ABI are extremely stable and most of the changes in interface are in rarely used features – but it’s still good to see it working in practice. I don’t need to worry nearly so much as I would have done previously about keeping other packages out of testing.

If you maintain a library written in C I would encourage you to take a look at implementing this, it’s very straightforward. Libraries written in other languages may cause more difficulty. There are some automatically generated symbol files in mole which provide a good starting point (I didn’t use them since upstream already had a more exact list of versions at which symbols were introduced) and support is already present in debhelper. The main things to watch out for when using the mole data are backwards compatible ABI changes which don’t just add new symbols (for example, if new values are accepted by a function) and variations between architectures.

Kudos to Raphaël for all the work he’s put into this.