krb5 transation: krb5 1.7

[Adeodato Simó]

+ Sam Hartman (Tue, 21 Apr 2009 15:54:06 -0400):

Hello, Sam, sorry for the delay on getting back to you, and thanks for
coordinating with us.

> Around a month ago, I had discussions of a transition to the krb5
> package on debian-devel.  The steps so far have been something that
> hasn't broken anything and I believe has been fairly low impact.
> However I'd like the release team's review for the next part and
> advice on one of two directions.

> Basically, the libkrb53 package is being split and will eventually go
> away.  Upstream is dropping support for the 1980's era Kerberos 4, so
> I need to drop the krb4 libraries.

> I've done the library split keeping libkrb53 .  However I'd like to
> move 1.7 into unstable, which means that libkrb53 needs to either go
> away or be produced by an oldlibs package based off the 1.6 sources.

> Anything that gets built now will not end up depending on libkrb53,
> but there are a large number of packages that do depend on libkrb53 in
> unstable.

> so, the question is whether we should BIN NMU those packages, or
> whether I should produce a krb5-1.6 source package to go into oldlibs
> for a while to keep libkrb53 around.  I'm happy to do the oldlibs
> package especially if it lets me get krb5 1.7 into unstable
> significantly faster.  I'm not happy to maintain the oldlibs package
> in a stable release; if we create such a package we should expect it
> to go away say sometime later this year.

> Unrelatedly, when Kerberos 1.7 goes into unstable,
> libauthen-krb5-admin-perl will break and require a source patch; I'm
> happy to coordinate with the maintainers of that package and supply a
> patch.

I say we go ahead without introducing an "oldlibs" package, and we
Bin-NMU the affected packages. Then, if the transition gets very hairy,
we'll migrate the new libraries to testing but retaining libkrb53 there
with britney, as we've done for some other transitions already. The
risk, as always, are applications that could end up loading both new and
old libraries at the same time, but the same risk exists with a package
in oldlibs AFAICT.

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

Cheers,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai