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.
> 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
> There are builds of these in unstable that do not depend on libkrb53.
> However there are build problems preventing builds on all
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.