Adeodato Simó <[EMAIL PROTECTED]> writes: > Particularly with respect the "I don't really want to break l-m-a-k in > testing immediately" and "that will mean that l-m-a-k may be broken in > testing briefly" bits: I don't know much of the interaction between > krb5 and l-m-a-k, but if the new krb5 breaks l-m-a-k, then a _real_ RC > bug should be in place against krb5 (and, pointing the obvious, one > knows of such brekage before krb5 enters testing because similar > versions are in testing and unstable). OTOH, if what you mean is that > l-m-a-k may break when compiled against the new krb5, then the RC bug > would go against l-m-a-k, and krb5 would migrate alone.
The RC bug was against libapache-mod-auth-kerb, since it grovelled around in deep library internals to turn off the replay cache. The version in testing will break horribly if libkrb53 1.4.3 is installed. In order to give people a chance to not have their Apache modules break, libkrb53 conflicts with the older version of libapache-mod-auth-kerb, but basically 1.4.3 going into testing will break the l-a-m-k in testing. I've been holding krb5 for two reasons -- one, I wanted to let the latest version age for 10 days (right now, it's aged for 8, which is probably good enough) and it accidentally acquired a high urgency; and two, I wanted a fixed version of l-a-m-k that would be able to propagate to testing at the same time or shortly thereafter. I think we're okay now; the new l-a-m-k won't get in there immediately, but after a day or two in unstable it can probably get forced in. > So, summarizing, perhaps I'm terribly confused, but whilst I > understand the existance of this bug to compensate the mistaken > urgency, I don't see why it should be coupled at all with a l-m-a-k > upload. Maybe I missed some part of the picture? I'm probably being slightly too conservative about l-a-m-k; it's mostly the mistaken urgency that the bug was intended to correct for. :) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
