krb5 libraries and circular dependencies

[Greg Hudson]

On Fri, 2010-05-28 at 13:43 -0400, Sam Hartman wrote:
> I have not previously analyzed the situation where libk5crypto continues
> to provide all the symbols it used to provide at the same symbol
> versions.

Well, let's take a harder look.  The most workable proposal is to:

  * Build and install a libkrb5 containing all of the objects currently
in libkrb5, libk5crypt, and libkrb5support.

  * Build and install a libk5crypto and libkrb5support containing all of
the same objects as in the (new) libkrb5.  Neither of these would be
mentioned by krb5-config; they would be ABI compatibility shims only.
(Well, and shims for builds which explicitly link against -lk5crypto
and/or -lkrb5support instead of using krb5-config.)

The effect would be to add a lot of symbols to all three libraries, and
not take any away.  The complexity burden for us would be low, since we
wouldn't need to maintain separate export or object lists for
libk5crypto and libkrb5support.  There would be some modest space
penalties (disk space for the install, address space for non-rebuilt
binaries and those explicitly linking against libk5crypto).

A possible concern is a process using Yarrow from both libkrb5 and
libkrb5support during the transition period.  For instance, a rebuilt
binary might use Yarrow from libkrb5, and also via a non-rebuilt
intermediate library (like OpenLDAP or SASL) which uses Yarrow from
libk5crypto.  In this case, each Yarrow would be using a separate y_ctx.
I don't think this would be a real problem (each PRNG would be seeded by
different OS random data), but I'm not 100% certain.