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
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
