Re: Next steps for krb5 transition: removals or fixes?
Sam Hartman wrote:
>
> Hi. Thanks for all your help with the binary NMUs and for analyzing
> my plans and giving suggestions.
Hi Sam
> I'm assuming there are some complications I don't know about it as
> debian-release currently has a block on krb5.
I guess that's only because it's not ready to migrate yet anyway.
> There are also a few complications I do know about in the form of
> things in testing that still depend on libkrb53. My preference would
> be to allow libkrb53 to stay ing testing as a binary package. It has
> no file overlaps with the libraries in the 1.7 packages; it simply
> contains two libraries that are no longer part of the package and
> depends on the packages that contain the retained libraries. So, as
> far as I can tell, if krb5 and libauthen-krb5-admin-perl migrate from
> unstable to testing and libkrb53 is retained in testing, nothing
> breaks.
> There are builds of these in unstable that do not depend on libkrb53.
> However there are build problems preventing builds on all
> architectures.
I've put the corresponding bugs in Cc so we can hopefully get input on
whether it's better to remove them from testing for now or a fix is pending.
> Package: gtorrent-viewer
> As best I can tell this is just broken in unstable.
Right, an upload that fixes it would be appreciated.
> Root-system is newer in testing than unstable and has RC bugs open for
> a long time in unstable.
Should this be fixed from testing for now?
> Package: libzephyr3-krb
> Package: zephyr-server-krb
>
> Zephyr's Kerberos support has been broken for a while in testing, so
> breaking libzephyr3-krb and zephyr-server-krb's dependencies in
> testing won't be a big deal. The code doesn't work. Zephyr is
> uninstallable and unbuildable in unstable. The version in
> experimental builds and installs but the maintainer does not believe
> it works. The maintainer is aware of the situation and has taken over
> upstream development of the package. Non-backward compatible protocol
> changes will be required. So, this is already kind of broken, isn't
> getting fixed soon, but is under control as best it can be with
> limited time.
So this should probably be removed from testing for now.
> I think moving krb5 into testing when its 10 days are up (or
> relatively soon) would be good. This is in part because after I
> reverted the symbols file change as we discussed, packages in unstable
> are beginning to stall behind krb5. Since I think we can move it into
> testing without breaking anything I think it is desirable to do so.
> On the other hand I'll certainly understand if you want to wait until
> more dependencies go away from libkrb53.
Well, it would indeed be better to have some more reverse dependencies
transitioned to krb5.
> Also, as I said, I don't understand how this interacts with other
> transitions. If you do think it makes sense to wait more than 10 days
> before trying to migrate krb5, please let me know. In that case I'll
> upload something based off 1.7 instead of 1.7~beta3. As I mentioned
> earlier, there are no code changes with that upload so there's no
> particular desire to do that before a testing migration.
I'm not sure how long it will take still, though uploading the new
version should be fine as I expect to have at least one other sourceful
upload for (one? of) the above packages.
Cheers
Luk
Reply to: