Hi Sam,

Thanks for the detailed followup.

On Thu, Jun 04, 2009 at 05:10:56PM -0400, Sam Hartman wrote:
> As best I can tell these symbols were only ever available with the
> KRB5_PRIVATE preprocessor define set in the compilation environment.
Oops. :-)

> Symbols made available by the KRB5_PRIVATE symbol are not part of the
> public ABI/API of the krb5 libraries.  They may be renamed, removed,
> arguments changed without updating the soname or elf version.  In
> general new symbols are added to k5-int.h rather than put in krb5.h
> with KRB5_PRIVATE.  From time to time more symbols are migrated from
> krb5.h to k5-int.h.

> Arguably when these symbols were migrated they should have been
> renamed.

> To address this bug, I could do a number of things including adding a
> #error to the krb5.h that gets installed if krb5_private is defined.
> I could also rename the symbols in question or see if upstream would
> do that.
Samba 3 relies on these symbols at the moment, so Samba 3 fails to build 
on Sid at the moment, primarily because configure finds the symbols but 
there is no prototype present. We already try to avoid using these
symbols if we can't find them.

If its doable, it would be nice if the symbols could at least be renamed 
upstream so that configure (especially in older versions of Samba) doesn't 
find them and existing versions of Samba 3 don't end up trying to use these 
functions.

> However I suspect a far more important thing to address is whether we
> can get to a point where you don't need private symbols.
> krb5_kt_free_entry is probably fairly easy.  There is a comment in the
> krb5 1.6 krb5.h saying to use krb5_kt_free_entry_contents instead.
Thanks, I'll fix this upstream. 

> The other symbols may be more problematic.  We can discuss via e-mail
> or IRC.
The only other symbol was krb5_auth_con_setreq_cksumtype. Do you know any 
alternatives for that one?

Cheers,

Jelmer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to