krb5 transation: krb5 1.7

[Sam Hartman]

    Adeodato> I say we go ahead without introducing an "oldlibs"
    Adeodato> package, and we Bin-NMU the affected packages. Then, if
    Adeodato> the transition gets very hairy, we'll migrate the new
    Adeodato> libraries to testing but retaining libkrb53 there with
    Adeodato> britney, as we've done for some other transitions
    Adeodato> already. The risk, as always, are applications that
    Adeodato> could end up loading both new and old libraries at the
    Adeodato> same time, but the same risk exists with a package in
    Adeodato> oldlibs AFAICT.
Briefly, agreed, although I don't think the risk of applications
loading the same libs exists.  In detail: 
 The libkrb53 package has no
overlapping libraries with libraries in any package in unstable.
We're removing two libraries entirely; the sonames of interfaces that
were public in Kerberos 1.6 have not changed in 1.7.  Binary
compatibility is retained except for applications that link against
libkrb4.so.2 or libdes425.so.3.  So, I don't think we have a risk of
applications loading libraries from libkrb53 that are also elsewhere.

(libkadm5srv became libkadm6srv and libkadm5clnt became libkadm6clnt.
These are private interfaces in 1.6 and public interfaces in 1.7.  The
only thing in unstable that links to them are the krb5 source package
and libauthen-krb5-admin-perl, which I mentioned in my first mail.)


    Adeodato> Can you let us know when you have uploaded to unstable?

I'll write back and let you know when I've uploaded.  However, that
should not stop you doing bin NMUs.  As of 1.6.dfsg.4~beta1-9 (-13 is
in unstable and testing) packages built against libkrb5-dev will not
depend on libkrb53.  That is, ywith the exception of
libauthen-krb5-admin-perl, anything you bin NMU today will not require
a rebuild after 1.7 hits unstable.