Internal MIT Kerberos functions used by Samba

[Will Fiveash]

On Wed, May 31, 2017 at 12:40:39PM -0400, Simo Sorce wrote:
> On Wed, 2017-05-31 at 11:53 -0400, Greg Hudson wrote:
> > The real reason I followed up was to ask a question about the libkrb5
> > soname.
> > 
> > For libkadm5clnt, libkadm5srv, and libkdb5, we install a header file
> > with a comment noting that the API isn't stable, but we do change the
> > library soname (via LIBMAJOR in Makefile.in) each time we make
> > incompatible changes to the ABI.
> >
> > For libkrb5, we haven't changed the soname in a long time; it has
> > sat at libkrb5.so.3 since release 1.2.  My hazy understanding is
> > that changing the soname would impose a moderate maintenance cost on
> > downstream distributions, but I don't know the magnitude of that
> > cost.
>
> For a foundational library like libkrb5 which is linked in a lot of
> software I would define the cost high, it basically requires a rebuild
> of all dependent code, and it mans incompatibility with existing
> binaries, which may or not be rebuildable (source code not always
> available or FTBFS issues may arise).

I agree with Simo, please do not change the soname of libkrb5.

> > So if we do install a header file prototyping some semi-public
> > libkrb5 functions, and later change them, do we plan to bump the
> > library soname?
> 
> Well, in theory if you change exposed symbols you should, independently
> of whether there are header files or not.
> That said, if this is a private API, marked as so, I do not see why you
> would bump the soname. I would though, change the symbol name, and
> either maintain a compatibility symbol or have the header use some
> dload() trick to check if the symbol is available and gracefully fail
> if not.

Also agree with Simo's suggestions.  Backwards runtime compatibility is
a big deal for Solaris.  For private APIs, if they change then we can
rebuild the internally delivered binaries that have a dependency on
those interfaces but because we do not want to force customers/third
parties to recompile binaries depending on public APIs Simo's advice
above is what I also recommend.

> >  If we do, it imposes some cost; if we don't, I think it basically
> > means the Samba package breaks if you upgrade libkrb5, which a
> > downstream distribution might not want to tolerate.
>
> This can be handled in other ways:
> - symbol versioning
> - dload() tricks
> - let distributions care for it
> - provide a stable wrapper you are ok exposing in the public API/ABI

-- 
Will Fiveash
Oracle Solaris Software Engineer