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

[Sam Hartman <hartmans@debian.org>]

>>>>> "Sam" == Sam Hartman <hartmans@debian.org> writes:

    Sam> OK, so I think we're all set.  The plan now is to

    Sam> 1) Build twice, once into build and once into build-krb4.  We
    Sam> only pull libkrb4.so out of build-krb4.  2) 

This works at least.


    Sam> 3) Make libkrb53 depend on all the libraries it now contains
    Sam> and libkadm55 depend on the libraries it contains.


    Sam> 4) Set up symbols and shlibs files to point everyone at
    Sam> libkrb53 and libkadm55 as appropriate.


It turns out this fails impressively.  The problem is that the library
packages depend on each other.  So, for example, libk5crypto3 is
needed by libkrb5-3.  If I make the shlibs file for libk5crypto3 point
to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on
libkrb53.  But libkrb53 depends on libkrb5-3 because that is the point
of libkrb53 in the new layout.

I probably could hack something that would work: use symbols files
that point at the split library packages internally and just before
the debs are constructed run a sed script on symbols and shlibs.


However as you'll recall the only reason we didn't point the shlibs at
the new packages initially is to make things easy for unstable
packages that get rebuilt while the new krb5 is waiting to migrate to
testing.

My proposal now is to upload with urgency medium.  There are no code
changes , I have high confidence that I can shake out any packaging
bugs in five days, and that provides a good compromise in my mind at
least between not blocking other people too much and having a simple
enough transition strategy that I can have high confidence I
understand it and that it will work.

If that sounds too problematic then I can investigate the option of
symbols files with alternatives (I.E. libk5crypto3|libkrb53 in the
symbols file.




 and In addition, either versioned replaces
don't work as well for downgrades as unversioned replaces, or replaces
on unpacked but not configured packages don't work as well as replaces
on installed packages.

I'll use unversioned replaces if the user experience is better,
versioned replaces otherwise.  (I had used unversioned replaces in
experimental, but was trying versioned in my current work).