[Pkg-xmpp-devel] gsasl_1.4.0-2_i386.changes REJECTED

[cascardo at minaslivre.org]

On Fri, Feb 05, 2010 at 03:38:26PM +0100, Simon Josefsson wrote:
> cascardo at minaslivre.org writes:
> 
> > I've done similar experiments here and my program worked all right too.
> > So, I thought I've missed something that we had back in the days we had
> > a problem with dicod. But, then, you've tried everything we dicod and it
> > works nicely too.
> 
> Yeah, we may still be missing something, but everything I've tested so
> far seems to work -- the warning message that is printed by rtld is the
> only exception.  I'm going to file a glibc bug about that, though, since
> it makes adopting version scripts for shared libraries more difficult.
> It is not a critical problem, though.
> 
> > But, anyway, we've been having problems with other programs. Basically
> > the issue seemed to be an old gcrypt version, right? So, we just need to
> > investigate now how we can make gsasl pull the right version
> > automatically.
> 
> The libgcrypt issue is very different!  It has nothing to do with shared
> library versioning.
> 
> The libgcrypt problem is triggered by this code in libgsasl:
> 
>       if (gcry_check_version (GCRYPT_VERSION) == NULL)
>         return GC_INIT_ERROR;
> 
> In other words, if libgsasl is used (during runtime) with a libgcrypt
> version OLDER than it was built with, it will refuse to work.  This
> happened here because libgsasl was built against libgcrypt in unstable,
> and libgsasl entered testing but libgcrypt did not -- so users installed
> the broken libgsasl.
> 
> This problem is fixed by adding a >= dependency on the libgcrypt version
> used when building libgcrypt.  It would be nice to find an automatic way
> to deal with this, but I don't know how to...
> 
> > And I think that's why we have the symbols and the old shlibs files. I
> > think we must push that into gcrypt package. What do you think?
> 
> That is not require to fix the libgcrypt issue.
> 

Yeah. I thought the problem was other one. Now that I understand the
problem, do you have any reasons besides simplicity to require the same
version it was built with, instead of requiring a particular minimal
version?

Maintaining the current implementation, I would suggest generating a
shlibdeps with the current version and let dpkg do the job. Otherwise,
we may risk build with a version and the buildd build with a different
version (and make it difficult to backporters to build with a different
version).

> /Simon

Regards,
Cascardo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-xmpp-devel/attachments/20100205/be19e74c/attachment.pgp>