Looking at this more closely, this do not appear as problematic as first can be thought. The patch I proposed earlier solves a problem on mixed stable/testing systems (such as for the original bug reported). There is no need to bump the shared library version of libgsasl7, which Cascardo and I have discussed on the XMPP mailing list.
Here is what I'm trying. Create gsasl.c: #include <gsasl.h> #include <stdio.h> int main (void) { printf ("header %s library %s\n", GSASL_VERSION, gsasl_check_version (NULL)); return 0; } Install libgsasl from stable: apt-get install libgsasl7/stable libgsasl7-dev/stable Build the tool: j...@mocca:~$ gcc -o gsasl gsasl.c -lgsasl Invoke it: j...@mocca:~$ ./gsasl header 0.2.26 library 0.2.26 j...@mocca:~$ Now install libgsasl from testing, which has versioned symbols: apt-get install libgsasl7/testing libgsasl7-dev/testing Do NOT rebuild the application, just invoke it again: j...@mocca:~$ ./gsasl header 0.2.26 library 1.4.0 j...@mocca:~$ This works fine, and indicates that 1.4.0 is backwards compatible with 0.2.26 (at least for this simple test function). Now rebuild the application using 1.4.0: j...@mocca:~$ gcc -o gsasl gsasl.c -lgsasl Invoke it: j...@mocca:~$ ./gsasl header 1.4.0 library 1.4.0 j...@mocca:~$ That's expected. Now install the old libgsasl, without symbol versioning: apt-get install libgsasl7/stable libgsasl7-dev/stable Then invoke the tool again: j...@mocca:~$ ./gsasl ./gsasl: /usr/lib/libgsasl.so.7: no version information available (required by ./gsasl) header 1.4.0 library 0.2.26 j...@mocca:~$ This is the same warning message that the original reporter got. However, note that the tool appears to work. Thus it seems that if you build a tool (i.e., dicod or my example above) using a modern version of libgsasl7 and then run the tool with an older version of libgsasl7, the tool will still work fine but you will get a linker warning. In other words, the ABI of libgsasl7 is both forwards and backwards compatible. The reason for the warning, though, is not in libgsasl7 -- it is that the tool was built incorrectly if the intention is that the tool should work without warning on both old and new libraries. However, I don't think debian makes any guarantee that this should work. If you upgrade a tool to the version in unstable or testing on a stable system, you may need to pull in whatever dependencies it has too, and essentially "you are on your own". It would be nice if these dependencies were automatically installed, though, and my patches takes care of that (but dicod needs to be rebuilt against a newer libgsasl7 for it to work). Going back to dicod, here is what I get if I install dicod (2.0-7) with libgsasl from stable: mocca:/home/jas# ps auxww|grep dico root 20050 0.0 0.0 4808 800 pts/4 S+ 09:44 0:00 grep dico mocca:/home/jas# /etc/init.d/dicod start Starting dictionary server : dicod/usr/bin/dicod: /usr/lib/libgsasl.so.7: no version information available (required by /usr/bin/dicod) failed! mocca:/home/jas# ps auxww|grep dico dicod 20068 0.0 0.0 6792 596 ? Ss 09:44 0:00 /usr/bin/dicod root 20079 0.0 0.0 4808 796 pts/4 S+ 09:44 0:00 grep dico mocca:/home/jas# Note that dicod is running! Launching it from a terminal works too: mocca:/home/jas# ps auxww|grep dico root 20212 0.0 0.0 4808 800 pts/4 S+ 09:45 0:00 grep dico mocca:/home/jas# /usr/bin/dicod /usr/bin/dicod: /usr/lib/libgsasl.so.7: no version information available (required by /usr/bin/dicod) mocca:/home/jas# echo $? 0 mocca:/home/jas# ps auxww|grep dico dicod 20217 0.0 0.0 6792 592 ? Ss 09:45 0:00 /usr/bin/dicod root 20222 0.0 0.0 4808 800 pts/4 S+ 09:45 0:00 grep dico mocca:/home/jas# This indicates that the problem is just in the dicod init.d script, which says 'fail' when the daemon outputs something on stdout/stderr. It doesn't notice that dicod was started successfully anyway. In other words, there is only a wishlist-kind of bug here. The problem is that the dicod init.d script says 'fail' where it should have said 'success', but the only situation where this happens if the user runs a mixed testing/stable system and install dicod using libgsasl7 from stable -- and that is not something that is supported. The patch I proposed does not hurt, though, and if libgsasl7 had that patch when dicod was built in testing, the user here could not have installed dicod without also automatically pulling in libgsasl7. However this is still only happening on mixed stable/testing systems, which, again, I believe is not something that is generally supported. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org