On Mon, 2006-12-11 at 12:45 -0800, Russ Allbery wrote: > Oh, there's a provides. Okay. I don't actually know how that works (I > should have checked that; sorry). I think a transitional package is still > better, but a provides *may* be enough for aptitude to figure it out. I'm > not sure.
I'm in favour of a transitional package. We know it works, how it works and why it works... > My guess is that it would be better for the new package to take care of > it, since otherwise we're carrying around an old source package as well as > a transitional binary package. That seems unnecessary. The only thing that scares me is the NEW processing for the transitional package, which would be avoided by using the old source package to create the transitional binary package. This is probably an irrational fear. :) > BTW, are we just assuming no one uses the krb4 modules any more, or are > they now provided by some other package? (It may not be a bad assumption > that no one uses them; popcon says there are 34 installs but no votes.) They aren't provided by any other package. If I remember correctly, I couldn't get cyrus-sasl2 to build Kerberos 4 modules. The API has changed somewhere along the way, and the function prototypes aren't the same anymore. I may be wrong, but that's what I remember from a year or so back. (Digging around some old build logs, I find this example: kerberos4.c:247: error: incompatible type for argument 4 of 'krb_mk_priv') If someone can help get the krb4 modules to build in cyrus-sasl2, then we could completely replace cyrus-sasl2-mit and provide an upgrade path to both Kerberos 4 and Kerberos 5 users. -- Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
