[Pkg-xmpp-devel] gsasl_1.4.0-2_i386.changes REJECTED
cascardo at minaslivre.org
cascardo at minaslivre.org
Fri Feb 5 15:44:14 UTC 2010
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the Pkg-xmpp-devel