[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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

>>>>> "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?

    Sam> 3 Julien> Have you considered uploading a version of krb5
    Sam> 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

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


    Sam> unless I'm missing something).


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

Ah, I was missing something.  It allows us to decouple when we
generate a bunch of binary NMUs from when we turn off krb4.  When I
upload the new package, nothing breaks in unstable, so there is no
particular need for the release team to do anything under any time
pressure.


Reply to: