Re: SONAMEs

[Chad Hardin]

How about we make it standard coding practice to put a  
NSMutableDictionary ivar into every single class for every major  
release.  Then, if more ivars are needed during minor release upgrades,  
they can be held in the Dictionary ivar.  When the next major release  
rolls around, what was held in the Dictionary can be made into a real  
independent ivar, and the cycle continues.

This extra ivar can be uniformly called extra_ivars or something like  
that.  For most classes, it would never be used, but for those few  
times that a new ivar is needed, it would not hurt anyone.

No, this is not my own original idea, but I do think it is  a decent  
one.  Of course, implementing it would mean *totally*  breaking binary  
compatibility, but at least it would only happen once.

Comments?  Am I overlooking something?

Chad


On Jun 19, 2004, at 12:58 PM, 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. (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
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep