krb5 libraries and circular dependencies

[Nicolas Williams]

On Fri, May 28, 2010 at 01:14:44PM -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.  That's a
> dramatic change for those of us distributing krb5.  From the Debian
> side, it means that testing transitions are blocked until all
> dependencies of krb5 are rebuilt.  Practically it means that
> dependencies of krb5 don't move into testing for around 4 months.
> Obviously, that means that the integration of krb5 needs to be carefully
> managed to find a time when this hit can be made.  The complications for
> Ubuntu are harder to analyze.  Sometimes, Ubuntu is impacted by Debian
> testing transitions--for example when preparing a long-term support
> release.  Other times Ubuntu is less impacted by these sorts of issues
> than Debian.

On Solaris the way we handle moving shared object content from one
object to another is to leave behind a shared object that has "filters"
on the other, so that apps linked against the object that's being
removed continue to work.  Filters are a feature of the Solaris linker,
but you can easily emulate them with a little bit of C code that you
could generate with a script if need be.

> I think plugins should be encouraged to call into libkrb5 when
> appropriate: doing anything else seems to make writing plugins
> difficult.  I'm not sure the concern of loading the wrong libkrb5 is
> sufficient to need a solution, but I don't object to the mechanism of
> having a function that takes the address of data.

I would definitely not be concerned about loading the wrong libkrb5.
Distributions can easily ensure that that cannot happen with the bits
they ship, and users should know not to mix and match plugins built
against one libkrb5 with another -- DLL hell can result if they do.