GNOME Bugzilla – Bug 703290
Split goa parts of libgdata into a separate .so
Last modified: 2014-06-15 22:10:15 UTC
See https://bugs.launchpad.net/bugs/1193018 for the original bug report. Ubuntu mobile wants to use evolution-data-server 3.8 with Ubuntu Online Accounts but without the GNOME Online Accounts parts. (Ubuntu mobile includes Qt but not GTK). EDS' addressbook-backends/libebookbackendgoogle.so uses libgdata but I don't think it uses the GOA authenticator part. Because libgdata is just one .so and that .so is built against libgdata, Ubuntu mobile can't use that .so without ending up depending on GOA which depends on GTK and WebKitGTK. libebookbackendgoogle is pretty useful as it provides Google Calendar integration which can be directly used by EDS' UOA backend. Would it be possible for you to split the GOA authenticator part of libgdata to a separate .so? I suppose this is similar in some ways to bug 689685 with gcr.
Wouldn’t configuring libgdata with --disable-goa when building for Ubuntu Mobile work?
I don't think that would work very well since we use the same packages for Ubuntu Mobile as for Ubuntu and I'm not interested in regressing GOA support on Ubuntu since Ubuntu GNOME includes GOA.
Using the same packages for two distributions requiring different feature sets seems, to me as a non-packager, to be fairly awkward. The only way I can think of to do this in libgdata would be to change the --enable-goa configure option to be a tri-state (enabled, disabled, split), where the new ‘split’ option would produce two .so files: one containing libgdata (without GOA), and another one containing just the GOA code. The ‘enable’ option would effectively do the same, except it would link the latter .so file into the former to maintain API compatibility. In order to get this to work on Ubuntu Mobile, you’d have to use the --enable-goa=split configuration — but that would mean using that configuration on normal Ubuntu as well, which would mean patching and recompiling all dependent packages to link to the GOA-only library. In any case, unless you can think of a better solution, I’m very much against including that sort of complexity in libgdata’s build system. It would complicate testing even further, and I can’t see it being useful outside Ubuntu. Of course, there’s nothing stopping you carrying it as a package-specific patch, and I can try and accommodate that, but unless you can come up with a better approach to implement in libgdata (and I’m all ears :-) ), I suggest you review the way you’re packaging things for Ubuntu Mobile.
Resolving WONTFIX as per comment #3. Please re-open the bug if you've got any other ideas.