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

[cascardo at minaslivre.org]

On Thu, Feb 04, 2010 at 05:00:26PM +0100, Simon Josefsson wrote:
> cascardo at minaslivre.org writes:
> 
> > On Thu, Feb 04, 2010 at 04:47:37PM +0100, Simon Josefsson wrote:
> >> cascardo at minaslivre.org writes:
> >> 
> >> >> Yes, I'm beginning to suspect this is the only way out -- however it is
> >> >> very unfortunate that ADDING symbol versioning to a shared library
> >> >> actually breaks the ABI.  Compare libidn, the API has been stable since
> >> >> 2002 or 2003 or so, but adding symbol versioning this breaks.  It would
> >> >> be nice to find a way were old applications can also find the old
> >> >> symbols in a versioned library.
> >> >> 
> >> >
> >> > I agree. I ended reading gnu libc loader code to understand the bug
> >> > someone reported and ended finding out it was due to symbol versioning.
> >> > I may dig out the code again and point out the section to blame for
> >> > this. But I think the best thing to do in case it's not possible to not
> >> > break the ABI is to just stay out of symbol versioning until you have to
> >> > break it for any other reason.
> >> >
> >> >> I'm going to ask on the gnulib list if anyone has any bright ideas here.
> >> >
> >> > If you find out anything, please tell. I'd like to know.
> >> 
> >> I have posted this plea for help now:
> >> 
> >> http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/20569
> >> 
> >> One question is that if it makes sense to revert to unversioned symbols
> >> now that applications are already linked to versioned libraries.  I
> >> would need to increment the shared library version for that change too,
> >> as far as I can tell, and then I could as well increment the shared
> >> library version AND continue to use versioned symbols in that new ABI.
> >> Incrementing the shared library version is arguable what I should have
> >> done when starting to use versioned symbols, though.
> >> 
> >
> > I didn't grasp this last sentence. Do you find it arguable to increment
> > soversion when starting using versioned symbols? What do you mean by
> > arguable? I find it undesirable. But if it breaks ABI, I'd say it's
> > necessary.
> 
> I meant that when I introduced versioned symbols, I should have
> incremented the shared library version, but I didn't do it, and that's
> the problem we'll need to deal with.
> 
> Now, if I knew back then that I had to increment the shared library
> version, I'm not sure I would have started to use versioned symbols,
> because increment the shared library version has some costs associated
> with it too, and it is not clear that the benefits of versioned symbols
> outweigh those costs.  Do you have a opinion here?  I still maintain
> some libraries that aren't versioned, and I'd like to avoid doing the
> same mistake again...
> 

I completely agree with you in this. I would have waited for any other
ABI break to use the opportunity to start using symbol versioning. I
don't find any other advantage to use symbol versioning besides avoiding
ABI breaks and soversion bumps. I'm going to read Ulrich Drepper's
articles again to try to find out any other advantage of using symbol
versioning and any reason to break ABI when starting using symbol
versioning.

> >> There could be some speed advantages in symbol versioning, but I'm
> >> wondering if it is really worth these pains.  I hope I'm just missing
> >> some basic insight...
> >> 
> >> Btw, is this mailing list archive somewhere?
> >> 
> >
> > It is at http://lists.alioth.debian.org/pipermail/pkg-xmpp-devel/.
> 
> Thanks, useful for referencing this discussion, I have a feeling I will
> want to point at this discussion later on.
> 
> /Simon
-------------- 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/20100204/eaff39b8/attachment.pgp>