An additional complication with the kadm5 sonames
hartmans at MIT.EDU
Wed Jan 13 13:47:05 EST 2010
>>>>> "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
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
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.
More information about the krbdev