krb5 transation: krb5 1.7

Sam Hartman hartmans at debian.org
Mon May 4 22:30:31 UTC 2009


Thanks for all your help!

>>>>> "Adeodato" == Adeodato Simó <dato at net.com.org.es> writes:
know when I've uploaded.  However,
    >> that should not stop you doing bin NMUs.  As of
    >> 1.6.dfsg.4~beta1-9 (-13 is in unstable and testing) packages
    >> built against libkrb5-dev will not depend on libkrb53.  That
    >> is, ywith the exception of libauthen-krb5-admin-perl, anything
    >> you bin NMU today will not require a rebuild after 1.7 hits
    >> unstable.

    Adeodato> Ah, but that's wonderful, since it means there's no
    Adeodato> really a transition in the britney sense, where all
    Adeodato> packages have to migrate at the same time. Rather on the
    Adeodato> contrary, rebuilt packages (except
    Adeodato> libauthen-krb5-admin-perl) can migrate to testing and
    Adeodato> their own pace, and krb5 itself will follow together
    Adeodato> with libauthen-krb5-admin-perl, after all of the rest
    Adeodato> has migrated.

That was the goal, although I'm suspecting that reality will be a bit
more difficult.  Some symbols have had their versions increased in the
1.7 packages because new flags were added to the functionality.  So,
it's possible that if some of the BIN NMUs take until after krb5 1.7
hits unstable, their shlibdeps may end up higher than is strictly
necessary.  (There is no way in a symbols file to say that if the
caller calls gss_init_sec_context without the deligate policy flag
that 1.6 is good enough, otherwise 1.7 is used--dpkg-gensymbols
doesn't even have the information to make that evaluation).

So, I think that we can make this a really small transition, but
perhaps not empty.

Unfortunately, it looks like some of the BIN NMUs are failing and some
of the failures use symbols with newer versions.  For example it seems
like cvsnt FTBFS on all arches.  More puzzling is the openssh build
failure on mipsel.  In that case, deny_severity from tcp-wrappers is
causing a problem.  It's a weak symbol exported by libwrap, that is
often redefined by the application.  sshd does in fact redefine the
symbol, but the mipsel linker complains about a non-dynamic reference
to a dynamic symbol.  I *think* the mipsel linker is wrong here, but
if so, that may prove ugly to fix.

However those are the only problems I'm seeing in the builds that have
completed so far, so I think this is going to be relatively painless.
In particular, the cups builds seem to be going well; so do the SASL
builds.  Those are the ones with the most rdeps.



More information about the pkg-perl-maintainers mailing list