On Sat, Nov 12, 2005 at 07:36:46AM +1100, Brian May wrote: > >>>>> "Andreas" == Andreas Barth <aba@not.so.argh.org> writes: > Andreas> Hi, while my regular "clean up RC-bugs"-work I noticed > Andreas> that the package krb4 is RC-buggy in more than one > Andreas> way. On further investigation, I also noticed that > Andreas> kerberos 4 is dying right now, and also that the bugs are > Andreas> not as easy to fix. Also, upstream doesn't look too > Andreas> active according to http://www.pdc.kth.se/kth-krb/. For > Andreas> this reason, I started to consider to push dropping of > Andreas> the krb4-package from unstable. This has some influence > Andreas> on the heimdal-package, and also on the release notes for > Andreas> migration issue. However, I personally tend to go that > Andreas> way. Please see bug #315059 for some discussion; > Andreas> especially, heimdal in experimental stopped to depend on > Andreas> kerberos 4. > Not only that, but it conflicts with key krb4 libraries (libroken and > libsl) IIRC. More likely: Conflicts/Replaces/Provides. I expect that if the Heimdal versions of libroken and libsl conflict with the existing krb4 versions, it's because they are in fact a compatible replacement. Hmm; looking at the symbol tables of each library, we have the following symbols that were present in the krb4 version of libroken and have been dropped in the heimdal version: get_progname roken_glob roken_globfree set_progname At least get_progname and set_progname were exported as part of the published API, so libroken16-heimdal can't claim to provide libroken16-kerberos4kth. It would be nice if upstream changed the soname, though, to distinguish it from other, known-incompatible versions out there. For libsl, the only symbol dropped is get_progname, and that doesn't seem to be part of the exported interface for libsl0 as of 1.2.2-11.3. So it may be valid for libsl0-heimdal to maintain package compatibility with libsl0-kerberos4kth, but this probably needs to be confirmed upstream. For libotp0, no symbols were dropped. So libotp0-heimdal should either Conflicts:/Replaces:/Provides: libotp0-kerberos4kth, or simply keep the same libotp0-kerberos4kth name. The latter is actually more useful, given that existing packages that depend on libotp0-kerberos4kth have a *versioned* dependency that can't be satisfied by the use of Provides. If all this is done correctly (libroken soname change, keep the historical package names of the other two libs), users who still need krb4 support locally should be able to keep around the krb4 packages from sarge as long as they need to while still being able to install heimdal from etch. > Ideally I thin the krb4 maintainer should have same say. > However I haven't heard from him. Well, normally package maintainers have a say in the removal of their own packages by responding to the RC bugs in them... > I think there several things I want to do before uploading Heimdal to > unstable as it is in experimental: > * Find out what packages will break. By the update of heimdal, it should only be packages depending on libgssapi1-heimdal, I guess? By the removal of krb4: (old) heimdal, and libsasl2-modules-kerberos-heimdal (from cyrus-sasl2). The only other packages in the archive with a dependency on krb4 today are lsh-server, libsasl2-modules-gssapi-heimdal, and sasl2-bin, which pull in the dependency via heimdal; and a build of samba which seems to have picked up a gratuitous krb4 dependency when built on my system... > * Find out what packages will still be broken even after recompiling. If anything has to be recompiled which *doesn't* depend on libgssapi1-heimdal, then that's a bug that needs to be fixed in heimdal first... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature