libkdb-ldap and ABI stability

Russ Allbery rra at stanford.edu
Sat May 10 14:22:28 EDT 2008


Sam Hartman <hartmans at MIT.EDU> writes:
>>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

>     Russ> On the other hand, that's a lot of hacking on MIT Kerberos's
>     Russ> build system and special modifications I'd need to maintain
>     Russ> for Debian, and your build system just installs it in the
>     Russ> regular public library directory.

>     Russ> So... what are the plans for this library?  Can I safely
>     Russ> package it as a regular shared library and rest assured that
>     Russ> the SONAME will change with any future backward-incompatible
>     Russ> change to the interface, such as what's apparently currently
>     Russ> in Subversion?  Will it ever have a public header?  Or would
>     Russ> it be better to install it into /usr/lib/krb5 and use RPATH
>     Russ> to find it (and if so, is that a patch you'd take back)?

> I think you should package it with no package installing a .so for it
> and add conflicts as appropriate when the functionality changes.

It turned out to be fairly easy (two lines of Makefile.in changes and a
couple of lines in debian/rules) to put the library into /usr/lib/krb5
instead of /usr/lib, signalling that only the program and plugin shipped
with krb5-kdc-ldap should even try to use the library, and build the
program and the plugin with an RPATH pointing to that directory.  Since
there's no *.so and no header files for it, that seems right to me, and I
was planning on going that route.  Is there any reason that you can think
of why doing that would be a bad idea?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the krbdev mailing list