pidgin.next.major: dbaa022b: We want libpurple.so.1, not libpurple.so...

[John Bailey]

On 03/16/2011 10:54 AM, Richard Laager wrote:
> Keep in mind that we're concerned with libtool versioning. Then it's up
> to libtool to deal with sonames. Other OSes might handle their
> versioning differently.
> 
> This might be helpful:
> http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#
> 
> Basically, since we started at 2.0.0, our interfaces correspond to minor
> versions (0 = 2.0.0, 1 = 2.1.0, 2 = 2.2.0, etc.). But each release
> supports all the way back to interface 0, since we didn't break
> backwards compatibility. If we release 3.0.0, it'll be interface 9, but
> we've stopped supporting interfaces 0 through 8.
> 
> If we ever want to release a 2.9.0 after 3.0.0, I think there's a
> potential for problems, since they'd both be interface 9. So we might
> want to pad lt_current for 3.0.0.

I expected the soname to have *some* correspondence with our version number.  It
took me *way* too long to grasp how this works.  I probably would have gotten it
more quickly if somewhere in one of those two pages the text had been forcefully
blunt and said that age indicates how many interface numbers backwards the
library is compatible with.  So I guess I'll undo my purple_lt_current change.
If we want to pad, how far do we want to pad?  Do we want to skip to 10, 11, 12,
... ?  Or do we want to do something really oddball and jump to something like 20?

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110316/68b7ecb2/attachment.sig>