Re: RFC: drop kerberos4-support?
>>>>> "Steve" == Steve Langasek <vorlon@debian.org> writes:
>> Not only that, but it conflicts with key krb4 libraries
>> (libroken and libsl) IIRC.
Steve> More likely: Conflicts/Replaces/Provides. I expect that if
Steve> the Heimdal versions of libroken and libsl conflict with
Steve> the existing krb4 versions, it's because they are in fact a
Steve> compatible replacement.
In theory at least...
Steve> Hmm; looking at the symbol tables of each library, we have
Steve> the following symbols that were present in the krb4 version
Steve> of libroken and have been dropped in the heimdal version:
Steve> get_progname roken_glob roken_globfree set_progname
The latest Heimdal version might have renamed these to glob() and
globfree(), hence clashing with the libc6 version of these functions.
Yuck. There should be configure tests to prevent these, but I am not
convinced they are working, as the header files were clashing (I don't
know what is going on here).
I can't remember now why our workaround was to rename the functions
instead of removing them. It is possible the roken version has
required features not in libc6. Double yuck.
libroken is probably the most important library. I suspect no package
other then Heimdal uses the functions in question, but I can't
guarantee it.
Steve> At least get_progname and set_progname were exported as
Steve> part of the published API, so libroken16-heimdal can't
Steve> claim to provide libroken16-kerberos4kth. It would be nice
Steve> if upstream changed the soname, though, to distinguish it
Steve> from other, known-incompatible versions out there.
At least some of these changes look like they are Debian specific, not
sure. So upstream changing the soname may not be appropriate.
Anyway, here is a quick scan of dependencies, at least in sarge:
(note: I filtered out Heimdal and kerberos4kth from these lists)
snoopy:~# apt-cache rdepends libroken16-kerberos4kth
libroken16-kerberos4kth
Reverse Depends:
sasl2-bin
lsh-server
libsasl2-modules-gssapi-heimdal
evolution-exchange
arla
snoopy:~# apt-cache rdepends libsl0-kerberos4kth
libsl0-kerberos4kth
Reverse Depends:
arla
snoopy:~# apt-cache rdepends libss0-kerberos4kth
libss0-kerberos4kth
Reverse Depends:
[ none ]
snoopy:~# apt-cache rdepends libotp0-kerberos4kth
libotp0-kerberos4kth
Reverse Depends:
[ none ]
snoopy:~# apt-cache rdepends libkrb-1-kerberos4kth
libkrb-1-kerberos4kth
Reverse Depends:
sasl2-bin
libsasl2-modules-kerberos-heimdal
evolution-exchange
arla
Build-depends kerberos4kth-dev:
Package: arla
Package: cyrus-sasl2
(note: just because a dependency is listed doesn't mean the library is
*used* by application. I suspect many applications blindly link using
"-lkrb5 -lsl -lroken", etc, because antique versions of libtool
couldn't handle interdependencies between shared libraries properly,
and there seems to be a lot of code that assumes libtool is still
broken - in actual fact "-lkrb5" is all that is required).
My proposed plan of action seems to be:
* Work out this glob() and globfree() business, and make sure I am not
creating duplicate symbols or using a version that is incompatible.
* Upload Heimdal.
* Rebuild above packages.
* If packages don't rebuild then it may be because it requires krb4
support => drop krb4 support (cyrus-sasl?), or entire package
(arla?).
* Drop kerberos4kth.
--
Brian May <bam@debian.org>
Reply to: