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