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

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.



Reply to: