Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman <hartmans@debian.org>]

>>>>> "Julien" == Julien BLACHE <jblache@debian.org> writes:

I really appreciate your help here!

    Julien> As you note in your second reply, the goal is to decouple
    Julien> the packaging change from the krb4 dismissal: 1 introduce
    Julien> libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on
    Julien> libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a
    Julien> versionned dependency on libkrb53 in libkrb5-dev

    Julien>  2 once it hits testing, change libkrb5-3.shlibs to point
    Julien> to libkrb5-3, version the libkrb53 -> libkrb5-3 dependency
    Julien> and the libkrb5-dev -> libkrb53 accordingly
    Julien> If you don't do (1), you risk being tied into other
    Julien> transitions by your rdeps as they'll be picking up
    Julien> dependencies on libkrb5-3 as they get uploaded in unstable
    Julien> as part of their own transitions or development cycles.

I'm sorry, but I don't see how I get stuck in unstable if I start out
with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
rather than libkrb53.  As I understand it, rdeps can only hold me in
unstable if moving my package into testing would make them
uninstallable in testing.

They depend on libkrb53  with a versioned dependency today.
A version of libkrb53 that is greater than any existing versioned dependency will be in my package migrating from unstable to testing, so their versioned dependency will be satisfied.
I don't know if we do build-dep related blocking today or not, but the build-deps on libkrb5-dev will continue to work.

In addition, since libkrb53 will pull in all the krb5 libraries a
package that depends on it will actually get the libraries it needs to function.

Now, I might hold my rdeps in unstable if for some reason it takes a
while for the new krb5 to migrate into testing.  However that's no
more true than if I added some symbols to one of my libraries and
upgraded my versioned dependency.  Still that's a reason to leave the
shlibs and symbols files pointing at libkrb53 until I make it into
testing.

The krb4 using packages are all leaf packages, so they will not
complicate things until libkrb53 goes away.


I trimmed the reply text, but you asked why I need two build passes.
The krb5 package includes a bunch of libraries as well as daemons,
utilities etc.  Building with krb4 enabled does more than build krb4
libraries, and I want to get the affects of building with krb4
disabled for daemons and utilities.  Doing two build passes will be
easy given my package structure and the package does not take
particularly long to build.

--Sam