Re: Fwd: akonadi 4 & 5 not coinstallable !

Daniel Vrátil <[email protected]>
Newsgroups gmane.comp.kde.users.pim
Organization KDE
Message-ID <1940271.HZVHGVyDul@odin>
On Thursday, November 26, 2015 8:16:45 PM CET René J.V. Bertin wrote:
> Hello,
> 
> I just received the message below, teaching me that Akonadi 4 and 5 are
> supposedly not co-installable.

Yes, they are not (on purpose).

> 
> I'm still a long way off from building either kdepimlibs5 or akonadi5, but
> the message did catch my attention.
> 
> It doesn't surprise me too much that one cannot run both at the same time
> (then again, maybe one can as long as there's only a single database server
> running). 

No. Although you can technically trick Akonadi to share a server with another 
Akonadi instance, doing so would eventually result in catastrophical data 
loss. 

> But I cannot help but wonder if the idea of appending a 5 to the
> names of the various agents (executables) hasn't been considered, like this
> has been done for so many other executables. Is it feasible to "patch this
> in"?

Renaming binaries is not enough. You would still get name conflicts on DBus 
and you would get conflict in config files - Akonadi has been using XDG dirs 
since the beginning, so both "Akonadi 4" and "Akonadi 5" would use ~/.config 
and ~/.local/share to store their configs/data.

> What is the more exact nature of the 4/5 conflict?

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. 

> The thread referred to
> makes a reference to the dependency of kdepimlibs on akonadi,

In KF5, kdepimlibs tarball/git repo only contains Akonadi client libraries.

> which also
> raises the question to what extent one can install KF5 applications that
> depend on kdepimlibs5 while also still using KDE4 applications that depend
> on kdepimlibs4 ?

kdepimlibs4 contained not just Akonadi client libraries but also many other 
libraries. Those "other" libraries have been split out from kdepimlibs.git in 
KF5 and are co-installable with those from kdepimlibs4.

There is no real conflict between kdepimlibs4 and any KF5-based KDE PIM 
library. The only real problem that occurs is that kdepimlibs4 and kdepimlibs5 
both require Akonadi at build time, which is not coinstallable.

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.

> NB: I am approaching this from OS X, where the actual KDE4 akonadi agents
> are built as "app bundles" which are installed in a dedicated directory
> that is different from the one where KF5 app bundles are installed. There
> won't be conflict at that level (even if the KF5 agents are built as
> regular executables).

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.

> 
> Thoughts?

We realize there are still some KDE4-based applications that need Akonadi and 
their port to KF5 is still underway (or not even started) and we understand 
that it may cause problems to some users. However the major changes that we 
did allowed us to move forward in a way that would not be otherwise possible. 
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.....


Dan

> René
> 
> -------------------------------
> Forwarded message:
> Date: Thursday November 26 2015
> Cc:
> Subject: akonadi 4 & 5 not coinstallable !
> 
> 
> Hi René,
> 
> did you know that akonadi 4 isn’t coinstallable with akonadi 5?
> 
> See this:
> 	https://mail.kde.org/pipermail/kmymoney-devel/2015-November/015825.html
> 
> Thought this might be good to keep in mind in case users install qt4-mac as
> well as qt5-kde!
> :)
> 
> Greets,
> Marko
> 
> 
> P.S.: Don’t be surprised if you hear little from me lately, as I am very
> rarely online with email these days. (I did a little port maintenance, but
> that’s more or less done for now.)
> _______________________________________________
> KDE PIM users mailing list
> Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users


-- 
Daniel Vrátil
www.dvratil.cz | [email protected]
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWV3SmAAoJEE1pVXrssTaD4e8QAJ5XoEZhZDMfEFxe1w74MV6Q
VrnIsC3E37d7t0mwmg/PbB6hiMT7GFrhL+ScFP0gB1xFT/kA4DDN3omGHFXwsftW
oIkUmaBVy+SsiIGyN5Vl5DaNzOf9imiH+wFfATOkUi1ktR7SQcKtO9AFW0O4zb5w
H9F8EfIYWrbnK/qQRvvIE4h5RBN1niCjmZPvXpAwOg8w8weK8s+k3pbB5liPviiK
G6tbtnIuBPJguDX6mFsJ3ecyUCmrjfx+5faGoZSOXPInqDVcBNOxMdeTxjUcsrH8
tNLY3i130mhkFFiruPVn6BjKFCsBJRafPPX3SNvucR6r1FfXT+h4fb2jdkfpVt/W
fqgVKT9f8VdvTYpbHbuNbKTy9ftLxnNnulIKdWc7IfOKJsq5iZF5gAj1fBC0yjRU
JCnB8mXRErI4ULfHQpaAslmhu69cd6G1sMxteUCfh9knUKawocKFT0i0/oYHHnT7
WlqgTe/CVhihsyCo/qgifDyB7xB9VDjL5Th36Kzk1iZMMgolvFy35ZXrEZmWFeYt
BfgvQ4ZI4/208Gp/klneUHuDBSTrApNfaYHzjS/1KAE5puvpI5B7lfXp0FIcs7gN
mCYYuLXY5FP0vgOzGkrmTgkTucF3sZ31B/d+t0ms6MSCLX59pq/7yOciRaykrmba
AiE9cnlD0b1IBslRM6LT
=1s68
-----END PGP SIGNATURE-----
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.