On Feb 16, 2004, at 9:34 PM, Peter O'Gorman wrote:
/usr/local/libs/libopenbabel.0.0.0.dylib
This would appear to have no versioning information at all. Is this version completely binary compatible with all previous versions? If not you should send the upstream authors off to read the library interface versions section of the libtool manual.
I *am* the upstream developer. I *have* read the libtool manual. This *is* the first shared library release. Period. Trust me.
because of course the shared lib version number should *not* be the same as the package version.
Indeed not, but it also should not be zero unless the library has not changed one iota since the first release (highly unlikely).
As I said. This is the first shared library release of the upstream code. Previous versions made quite clear comments that shared library support was *not* ready and should *not* be enabled. The fink packager, however, decided to define the not-ready-yet shared library as 1.100.0 which *clearly* is incorrect. (And didn't ask the upstream developers about it or we would have been happy to suggest a better library version number.)
I want to know why a package maintainer decides to define a shared library version without reading the libtool manual.
I want to know why fink really wants to define shared libraries for packages where the upstream developer doesn't think it's ready. I really don't think this is a good reason for exactly what's happening here. The upstream source is supposed to start with 0.0.0.
But that's water under the bridge right now, and we need to come up with a solution to this problem.
Well, you will have to hack the makefile again to make a compatibility and current version that is greater than the shared library built by the current package.
For the reasons I outlined, I really don't want to do that.
It makes a maintainer problem for fink, needing to constantly update the Makefile patch every time a new upstream release is made.
Worse, it would mean that a user compiling a program outside of fink would have to draw a distinction between the fink shared library (e.g. /sw/libs/libopenbabel.1.100.0.dylib or whatever) and an upstream /usr/local/libs/libopenbabel.0.1.0.dylb, which could be identical.
I don't think that's a good solution.
Option # is upstream. It's possible but I would not be particularly pleased if (putting on upstream developer hat) we have to define our library version starting at 1:100:1 (or probably higher, like 2:0:0) to get around the packaging problems with fink. I haven't checked if the fink shlibs package has an incompatible ABI/API with the new release. I'll do that shortly.
Any solution besides this? Any way the packaging interface versioning in fink can let us escape this mess?
-Geoff
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
