On Wednesday, January 15, 2003, at 10:59 PM, Max Horn wrote:
Actually, I just noticed a bug in your patch :-)
So, the only case to worry about is when AGE is non zero. As I see it, the new code should behave completly correct in that case, while the old code was simply wrong. The question is, what happens to compatibility with this change... well, anything that had a non-ZERO AGE will suddenly have a *lower* compatibility version. So potentially, problems might occur if a library with a non-zero AGE is rebuilt, but its dependencies aren't. Not sure how to make a smooth transition in that case.
example package - libfoo CURRENT 5 AGE 2 REVISION 1
builds:
libfoo.dylib
libfoo.3.dylib
libfoo.3.5.1.dylib
With your patch it becomes compatibility version 4 current version 4.5.1.
Next upstream release adds some interfaces again, removes none.
CURRENT 6 AGE 3 REVISION 0
builds:
libfoo.dylib
libfoo.3.dylib
libfoo.3.3.0.dylib
we get compatibility version 4 current version 4.3.0
Exceptionally uncool. The current version is _lower_ than the last release, note that the library names are okay, that is the libtool way :-), but dyld doesn't look at libs that way, the current version should always go up.
I think it should be building:
case 1:
current_version 5.1
case 2:
current_version 6.0
You are, of course correct with the compatibility versions, and I think it is worth getting this upstream even if it breaks binary compatibility on some of our installed packages.
Peter
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
