[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