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

[Daniel Vrátil]

On Thursday, November 26, 2015 11:10:12 PM CET René J.V. Bertin wrote:
> 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)?

Not really. We just percieve it as an update. You don't have kate5.2, kate5.3 
etc. just so that you can coinstall two updates...

> > 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 :-/

Does Digikam actually need Akonadi? If it only needs some of the kdepimlibs, 
that can be worked around (by either patching Akonadi from kdepimlibs, or 
patching Akonadi server from akonadi so that only the shared library is 
compiled).

> > 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).

In pure theory you can alternate "Akonadi 4" and "Akonadi 5" on top of the 
same database. In practice you don't want to do it.

> > 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!

Even if we make it co-installable, people will get the impression that they 
can run both at the same time - which they can't - and would mess up they data 
and spam us with bug reports about it. "Akonadi 5" is a natural upgrade of 
"Akonadi 4", there should not be a need to have both (yes, we unfortunately 
underestimated the amount of 3rd party apps directly or indirectly depending 
on Akonadi).

I switched to v5 immediatelly after we did the basic v4->v5 port and used it 
since, I never ran v4 with v5 in parallel as "development" version.

Dan

> 
> R.


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20151127/c29c7f0c/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users