Re: SONAMEs

[Eric Heintzmann]

On 2004-06-20 19:44:51 +0200 Richard Frith-Macdonald 
<richard@brainstorm.co.uk> wrote:

> On 19 Jun 2004, at 23:58, Eric Heintzmann wrote:
>
> > > 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.
>
> Actually, apps using NSUnarchiver and GSIMapTable will continue to 
> work fine.

In this case, why writing in changelogs there is binary 
incompatibility with NSUnarchiver, GSIMapTable ?

> However, Apps which *subclass*  NSUnarchiver  would need a recompile 
> (though
> I've not heard that there *are* any apps which subclass NSArchiver).

What about gnustep-gui and NSView and subclasses ?

> > (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) ?
>
> I agree that technically the library version should have changed ... 
> but the 
> risk
> of real binary incompatibility in this case seems tiny, so I wouldn't 
> think 
> it's worth
> making a new release to fix this ... especially as Adam said this is 
> more of a
> pre-release.
There is a chance that this pre-release will be the one in sarge...
But yes, if all apps continue to work, we can ignore these binary 
incompatibilities and there is no reason to update the soname now (I 
say soname and not lib version because they can be decoupled).

But is it possible to ignore the binary incompatibilities in 
gnustep-gui too ?

Eric