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

Re: RFC: drop kerberos4-support?

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:


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

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

Reply to: