Re: Fwd: akonadi 4 & 5 not coinstallable !
René J.V. Bertin <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <[email protected]> |
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