[kdepim-users] Fwd: akonadi 4 & 5 not coinstallable !

René J.V. Bertin rjvbertin at gmail.com
Thu Nov 26 22:10:12 GMT 2015


On Thursday November 26 2015 22:07:50 Daniel Vrátil wrote:
> On Thursday, November 26, 2015 8:16:45 PM CET René J.V. Bertin wrote:

> Yes, they are not (on purpose).

Dang :)

> The major conflict is absolute incompatibility in the protocol. There is no 
> way KDE4 clients can talk to Akonadi "5" server and vice versa. There was also 
> a major change in the DBus interface and some small changes in the database 
> schema. 

Wouldn't that have justified changing names all over, so that compatibility questions wouldn't have come up (or less likely so)?

> If a distribution is shipping KDE PIM >= 15.08 (i.e. KF5-based PIM), and only 
> needs some of the "other" libraries from kdepimlibs4 (like KAbc, KMime, 
> KCalCore, .....), it is possible to just patch the Akonadi client libraries 
> out from kdpeimlibs4. If the Akonadi client libraries are required, then it is 
> still possible to only compile the shared library from "Akonadi 4" (which is 
> co-installable with the shared library from "Akonadi 5") and omit all the non-
> coinstallable binaries.

To be very honest, I was planning to move KDE PIM over last. It's intricate (and frankly, fragile) enough to prefer not to meddle with it.
But things like Digikam and other kdepimlibs(4) dependents I might have were likely to migrate much sooner ... apparently that's going to be an issue :-/

> No idea how this works on OS X. As long as you are able to separate DBus 
> sessions, $XDG_HOME_CONFIG and $XDG_HOME_DATA for each instance, then you can 
> theoretically run "Akonadi 4" and "Akonadi 5" at the same time.

That's not the goal. As long as alternating different versions doesn't mess up the database I could conceive testing a v5 set-up, but my main concern for now is to be able to build things (while preparing MacPorts packaging stuff).

> The performance gain and memory usage optimizations alone were absolutely 
> worth it, not mentioning the improved maintainability and robustness of the 
> entire thing. To me this is a price worth paying.....

That's good news, but again, I don't really understand the interest of having kept the same names. That cannot have made things easier for you during development either!

R.
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users


More information about the kdepim-users mailing list