SONAMEs

[Eric Heintzmann]

> Noteworthy changes in version `1.9.2'
> =====================================
>
>    * GSMime parsing ignores extraneous data
>
>    * New log functions GSOnceFlag and GSOnceMLog
>
>    * New class NSError
>
>    * Multiple new function in GSObjCRuntime
>
>    * NSProtocolChecker rewritten
>
>    * autogsdoc support added for building frames
>
>    * Binary incompatibility:  NSUnarchiver, GSIMapTable have new ivars
>      added

I notice there is a binary imcompatibility, and that the soname is 
still libgnustep-base.so.1 (objdump -p libgnustep-base.so.1.9.3 | grep 
SONAME).
Why ?
Isn't there a rule that say:
 If a package keeps the same SONAME, it means that the BINARY 
COMPATIBILITY IS KEPT.

Why is it annoying ?
For example, in debian, when gnustep-base-1.9.2 will replace 
gnustep-base-1.9.1(soon), all apps using NSUnarchiver, GSIMapTable 
won't work any longer and users will have to wait that maintainers of 
these apps rebuild them. (And imagine that sarge is released before 
these rebuild...).
But if the soname was bumped up (lignustep-base.so.2 or 
libgnustep-base-1.9.2.so.1 for example), I could provide two packages 
: libgnustep-base1 and libgnustep-base2 (or libgnustep-base-1.9.2-1) 
that could be installed in parallel and all apps will work fine even 
if their maintainers forget to rebuild them. It seems really a better 
solution.
So please can you review your policy about libraries versionning to 
help package maintainers (and thus your final users) ?

Eric

I suggest to read this: (chapter 4, 5 & 8)
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#SONAMES