krb5 libraries and circular dependencies

[Greg Hudson]

On Fri, 2010-05-28 at 13:14 -0400, Sam Hartman wrote:
> I don't have a strong opinion on combining libk5crypto and libkrb5.  If
> you combine them it's important to bump the soname of libkrb5.

I don't want to bump the soname of libkrb5, and I don't think it's
strictly necessary.  We would only be adding symbols to libkrb5.  As for
libk5crypto, the options include:

  * Continue providing libk5crypto with all of the current public
symbols, as an ABI compatibility shim.  These symbols might only be used
by programs which linked against -lk5crypto without -lkrb5.

  * Continue providing libk5crypto with the same symbols as in the
combined libkrb5 (so it's a clone of libkrb5).  This might make the
build system simpler.

  * Provide an empty libk5crypto without bumping the soname.  This would
be a clear violation of ABI compatibility rules, but might not cause any
harm if (1) we assume that all apps linking against libk5crypto also
link against libkrb5, and (2) symbol versioning does not, as Ken
suggests they might, cause apps to care which library is providing their
symbols.

  * Provide an empty libk5crypto and bump the soname.  I think this is
just as painful as bumping the libkrb5 soname.

libkrb5support has similar options, except that we don't expect as many
apps to be linking against it directly since krb5-config does not list
it.