Bastian Blank <[EMAIL PROTECTED]> writes: > On Sun, May 04, 2008 at 11:03:39AM -0700, Russ Allbery wrote:
>> Please explain exactly how this is a bug. What breaks? What doesn't >> work properly? What problems does this cause? > Trunk (I did not check 1.6.4-beta1 yet) removes exported symbols from > the library without changing the abiname. This can be ignored under some > circumstance, but is not nice. Upstream has a tendency to do this for symbols that should never have been exported and has done this for libkrb5 in the past as well. I agree with you that the SONAME should really be bumped in this case. Regardless of how we package for Debian, I think this is an upstream bug in the upcoming 1.7 release and that they should fix it (since changing the SONAME of this library has much less effect than libkrb5 would). It's kind of annoying that this is a shared library at all rather than purely a plugin, since really the last thing that krb5 needs is yet more shared libraries. But I expect that writing the admin client without having a shared library shared with the plugin was too annoying for them to do. >> This is rather far from the only shared library in Debian that changes >> ABIs based on configuration options; > Please show an example. Especially if it changes data structures it gets > nasty, as the software usualy just crashs. I'm sorry about that. That was a stupid statement for me to make without specific examples in mind. I'm fairly sure that I've ran into this before, but really, you're right, that's fairly irrelevant. Whether other people do it or not, it's a bad idea. The krb5 package has several libraries that don't have any officially exported ABIs; the others are in the libkadm5 package. Those, however, appear to be fairly stable. There are just no header files for them, but there are programs that link against them anyway (although none packaged for Debian so far as I know). I've never had a good feel for how acceptable this sort of "unstable ABI" shared library package is permitted when there's no -dev package and no possibility of Debian packages outside of the same source package being linked against it. As long as the dependencies within the source package are sufficiently tight, I can't think of any specific problems inside Debian it causes, although it's definitely not clean. Hacking the build system with an RPATH and whatnot and getting that right sometimes feels to me like more trouble than just packaging such a "private" shared library, providing no -dev package, and ensuring the dependencies are sufficiently tight whenever anything changes. But I may well be off-base about this. > Generic shared library ABI handling is not defined by the policy. It is > defined by the runtime environment and the standards for that (ld.so, > ELF). If you believe you can handle that properly, feel free. But for a > private lib (the build system don't install headers which are needed to > build anything against it) this is just not worth the work. > > I would just remove the soname and install it as libkdb_ldap.so into > /usr/lib/krb5. kdp/kldap.so and krb5_ldap_util needs an rpath then. See, to me, that sounds like a lot more work hacking the upstream build system than talking upstream into changing the SONAME as needed. :) I've also gotten yelled at by OpenLDAP upstream for Debian changing their library build processes, so I'm a little gunshy. I agree that your proposal is cleaner in the general sense, though. I'm going to talk to upstream about this and try to figure out what their plans are for maintaining this library, and will see how hard implementing the above looks (it might be a lot easier than I think). Thank you very much for your patience and reasoned reply. I'm constantly finding more things I need to learn about how to do this. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
