Hello! A user just alerted me of the fact that he cannot use the precompiled SyncEvolution binaries on Ubuntu Intrepid, which ships Evolution 2.24. The reason is that the version of libedataserver was bumped from current/revision/age 10/0/1 to 11/0/0 as part of the r8703 commit (log message quoted below).
Why was it necessary to break backwards compatibility? The log message doesn't say. It mentions that some code was moved into a new library (libebackend?), but that alone doesn't necessarily break the backward compatibility: libedataserver1.2 could have been linked against libebackend. That way any symbol originally provided by libedataserver1.2-9 would still have been found. It doesn't matter in which library the symbol really is, because both libraries would be loaded and searched automatically. My nightly testing should have caught this change, but it didn't because the test binary was unintentionally relinked. Now that I have fixed this I get the expected "lib not found" error. After manually adding a libedataserver-1.2.so.9 symlink the binary runs. Unless I missed something, the new libedataserver could have been versioned as follows: LIBEDATASERVER_CURRENT=11 LIBEDATASERVER_REVISION=0 LIBEDATASERVER_AGE=2 With 2.24 I get: libedataserver-1.2.so -> libedataserver-1.2.so.11.0.0 libedataserver-1.2.so.11 -> libedataserver-1.2.so.11.0.0 libedataserver-1.2.so.11.0.0 With the suggested versioning I get: libedataserver-1.2.so -> libedataserver-1.2.so.9.2.0 libedataserver-1.2.so.9 -> libedataserver-1.2.so.9.2.0 libedataserver-1.2.so.9.2.0 Is there still a chance to mitigate the effect of this change? Downgrading the version as suggested above would be the most obvious solution, but unfortunately libedataserver-1.2.so.11 has been released already :-/ Another solution would be to create a libedataserver-1.2.so.9 symlink as part of the EDS installation. But then packagers still would have to be aware of it and declare that the package provides libedataserver-1.2.so.9. Can such ABI changes please be discussed on this list? I'm interested to hear about them beforehand and won't notice them if they are only discussed on IRC or in a bug tracker entry; there may be others in the same position. Thanks! In 2006 Michael Meeks wrote on this list that "I -thought- we had some agreement written in blood that the e-d-s ABI was now frozen." and in the camel Bugzilla entry #543389 Srinivasa again confirmed that "we support libebook/libecal as supported APIs". Does that include libedataserver? That library is necessary when handling more than just the default data sources because it provides the e_source_* calls. Therefore I consider it part of the libebook/libecal API - agreed? r8703 | rbradford | 2008-04-29 16:34:35 +0200 (Tue, 29 Apr 2008) | 35 lines 2009-04-23 Rob Bradford <[EMAIL PROTECTED]> * Makefile.am: * configure.in: * libebackend/Makefile.am: * libebackend/libebackend.pc.in: Build framework for new libebackend library. * libedataserver/Makefile.am: Remove files that have moved to libebackend. * libedataserver/e-data-server-module.[ch]: * libedataserver/e-db3-utils.[ch]: * libedataserver/e-dbhash.[ch]: * libedataserer/e-file-cache.[ch]: Moved to libebackend. * src/Makefile.am: * src/server.c: Use libebackend headers and link to the library. * docs/reference/Makefile.am: * docs/reference/libebackend/Makefile.am: * docs/reference/libebackend/libebackend-docs.xml: * docs/reference/libebackend/libebackend-sections.txt: * docs/reference/libebackend/libebackend.types: Add documentation for new libebackend library. * docs/reference/libedataserver/libedataserver.types: Remove types that have been moved to libebackend. * docs/reference/calendar/libedata-cal/Makefile.am: Add libebackend to the gtk-doc scanner libraries. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers