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

[Sam Hartman <hartmans@debian.org>]

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

    Julien> Sam Hartman <hartmans@debian.org> wrote: Hi,

    >> That is, if I made the dependency in libkrb5-3.symbols look
    >> like libkrb5-3|libkrb53 (and similar changes for other symbols
    >> files), then both the packages in unstable and testing would
    >> satisfy the dependencies.  It seems like this would
    >> significantly reduce the impact of the transition.  Am I
    >> missing something or would this change be a good idea?

3    Julien> Have you considered uploading a version of krb5 with: -
    Julien> libkrb5-3 - libkrb4-?  - libkrb53 a metapackage depending
    Julien> on both of the above - libkrb5-dev depending on libkrb5-3
    Julien> alone and containing only the files needed to link with
    Julien> libkrb5-3

That's undesirable because building without krb4 has some fairly
significant impacts on non-library parts of the krb5 packages.  So I
could not actually build with krb4 support disabled.  I guess I could
do two build passes one with krb4 support and one without (picking up
only the krb4 library from the krb4 build pass).


If I do something like this why do I want the krb4 libs to end up in a
new package we plan to get rid of reasonably soon?  Why not stick them
directly in libkrb53?  (krb4 libs in libkrb53 vs libkrb4-2 seems like
aa mostly asthetic issue unless I'm missing something).


Assuming that alternatives in the symbols file works, it seems like
the only difference between your proposal and my original proposal is
that it handles uninstalling libkrb53 somewhat better if one of the
packages that replaces files in libkrb53 is installed. It also allows
the new krb5 to migrate to testing ahead of waiting for everything to
be rebuilt.  If the alternatives approach works it means that both
approaches allow other packages to migrate to testing.

If there is some problem with the alternatives approach, then your approach is a clear winner.  

I actually think allowing the new krb5 package to migrate to testing
is worth a second build pass on the krb5 package, so I'll do roughly
what you suggest.  I assume that with this approach I don't need to
block on anyone for the first upload (the one with libkrb53 still
present) and can do so at my convenience.

I would appreciate your input on whether there is a good reason to
stick libkrb4 in a new package vs sticking it in libkrb53.  I'd also
appreciate your answer to whether the alternatives approach would work
to help sanity check my understanding in this space.


Thanks,

--Sam