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
