An additional complication with the kadm5 sonames

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On Wed, 2010-01-13 at 10:45 -0500, Sam Hartman wrote:
    >> Based on that I think a rename to libkadm5clnt-mit.so.7 would be
    >> better, but I'm happy with any solution that works.
    Greg> 5. One can imagine a setup where MIT and Heimdal use different
    Greg> library basenames and have symlinks for the "neutral" names,
    Greg> allowing development packages to be installed for both at the
    Greg> same time with an alternatives package deciding which one gets
    Greg> the neutral names.  Packages could link against either the
    Greg> neutral names or the package-specific ones, depending on
    Greg> whether they work with either implementation or just one.

    Greg> However, getting to this point would require much more than
    Greg> changing just the name of libkadm5clnt and libkadm5srv.  We
    Greg> would also need to change the basename of libkrb5, which we
    Greg> don't want to do any time soon since we don't like to change
    Greg> libkrb5's soname, and we would need to resolve the conflicts
    Greg> with header filenames (this could be handled through the
    Greg> include path) and the krb5-config binary.

I think pulling libkrb5 into point 5 in your message sacrifices
 practicality for theoretical correctness.  I think there are a lot more
 reasons not to change the soname of libkrb5 and I think there is
 significant value in a solution that does not address libkrb5.

    Greg> Also, it bears considering how much of this is an upstream
    Greg> source issue and how much is an OS distribution issue.
    Greg> Treating the soname part as an upstream source issue is
    Greg> reasonable since sonames should be compatible across Linux
    Greg> distributions.

Agreed.  I think the rest of it--handling the development libraries and
headers--should be a distribution issue.

    Greg> I am reluctant to perform a basename change for 1.8.  We've
    Greg> entered the testing cycle, it's a shorter one than we're used
    Greg> to for previous releases, and this does not feel like a
    Greg> conservative change.  

Note that libkadm5 has much less of a compatibility guarantee than other
libraries.  Why does changing the base name not feel conservative?

    Greg> At the moment I favor bumping the
    Greg> libkadm5clnt and libkadm5srv soname suffixes to 100 and
    Greg> declaring anything more comprehensive to be out of scope for
    Greg> this release.


I'd be comfortable with this approach if there was coordination with
Heimdal.  Without that coordination, the basename change seems like a
better bet.
One of the assumptions behind this position is that coordinating with
Heimdal is relatively easy on this matter.


A couple of factors to consider.

1) We've already changed the soname for libkadm5 in this release.  This
issue can be thought of as a bug that appeared in the testing cycle
directly responsive to that change.

2) While we don't have a high level of compatibility guarantee for
libkadm5, therea is still a cost to changing the soname.  It complicates
transitions from one version to another for distributions and people
deploying the software.  So, if we come up with an interim fix now, we
should defer something more permanent until we have some change that
justifies a soname bump.  I don't think this particularly argues against
an interim fix, simply argues about when it would be appropriate to move
to a next step.