Bug#3321: libgdbm.so version number...

["Arup Mukherjee" <arup+@cmu.edu>]

Mark Eichin writes:
 > could you give me more information on this? (I'm the current libgdbm
 > maintainer.) Calling it libgdbm.so.2.0 would really seem like a
 > mistake, since after all, libgdbm itself is only at 1.7.3... but I can

Well, it appears that the shared lib version number of libgdbm was
bumped to 2.0 at some point in the development of libc 5.2 ... see

   http://imageek.york.cuny.edu/pub/sunsite/HJL/release.libc-5.2.3
and 
   http://sunsite.kth.se/Linux/GCC/ChangeLog

I can't pretend to understand the reasoning behind this, but both
slackware and redhat appear to have gone along with it. If debian
doesn't have it, it's effectively going to lose binary compatibility
for programs using gdbm that were compiled on slackware or redhat. 

I guess the affected binaries fall into two groups: 

	(1) precompiled binary distributions of software. An altavista
search suggests that some releases of sendmail, NCSA httpd, and
kerberos at least are dynamically linked against a libgdbm.so.2.0

	(2) stuff compiled by endusers before they moved to debian. 

I hit category #2 (quite hard, since in my case it was a kerberized
/bin/login that wouldn't work!). The problem is worsened by the fact
that most people are not likely to realize that the missing 2.0.0 is
in fact the 1.7.3 lib they already have; I certainly didn't. 

So: I guess I'm suggesting an extra symlink just to maintain
compatibility with the other major linux distributions. Perhaps it
would be worth contacting H. J. Lu to find out the rationale for the
version number change. (He's the author of the info in both of the
URLs above.) I guess libgdbm was separated from the libc distribution
sometime after this version # change, but it would appear that most
people haven't dropped the version # back down after the split.

Thanks, 

-Arup