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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.