kopete and kdepimlibs in apps 15.08

Tue Aug 18 11:06:20 UTC 2015

On Tuesday, August 18, 2015 12:40:21 PM CEST Pali Rohár wrote:
> On Tuesday 18 August 2015 11:41:04 Daniel Vrátil wrote:
> > On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote:
> > > Hellos,
> > > 
> > > So, I just noticed that kopete has:
> > > > CMakeLists.txt:find_package(KdepimLibs REQUIRED)
> > > 
> > > we do however not have a kdepimlibs (qt4) in Applications 15.08 so
> > > that requirement cannot really be met anymore.
> > > 
> > > What's worse: kdepimlibs (qt4) in fact has file overlap with
> > > kdepimlibs (qt5); namely at least:
> > > - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml
> > > - usr/share/mime/packages/kdepimlibs-mime.xml
> > > so they are not co-installable without tweaking by every distro first.
> > 
> > kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5,
> > because that's what it contains. For the socialutil we could have x-
> > vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP.
> 
> Ok, then conflicting files are solved.
> 
> > However that's not the biggest problem. The biggest problem is that you
> > can
> > only compile kdepimlibs4 against Akonadi <= 1.13, which is not
> > co-installable with the version of Akonadi required by kdepimlibs5. The
> > one thing that kdepimlibs4 needs from Akonadi is
> > libakonadiprotocolinternals.so (that's what kdepimlibs4 link against). If
> > Kopete does not need to actually access KDE PIM data stored in Akonadi,
> > then the Akonadi(qt4) server or any other binary are not needed. We can
> > publish some sort of "manual" for distributions how to deal with this,
> > but I'm afraid distros will have to figure out the packaging magic to
> > handle that on their own.
> 
> Kopete does not depend nor does not use Akonadi. It uses old KABC
> resources. So it does not need Akonadi client or server.
> 
> But I'm not happy with such dependency problems. Why there are those
> problems? I do not understand these decisions. Nobody was thinking about
> problems with coexistence of older application? Or everybody did not
> care about that before KF5 relase? Is KDE again going to have with KF5
> same fuck-up as with first KDE4 version?

We somewhat expected that all kdepimlibs4 users have only optional deps or 
that they will switch to KF5 as well. Yes, we screwed up (again).

> 
> Writing manual for distribution is bad idea. It means that software
> collection (KDE4, KF5) is broken by design.
> 
> So why kdepimlibs4 cannot be compiled with same version of akonadi as
> kdepimlibs5? I think this is biggest problem which causing this, right?

There is this tiny library called libakonadiprotocolinternals.so which Akonadi 
server and kdepimlibs share. It contains some utility classes and macros 
related to the communication protocol. The protocol has changed substantially 
in Qt5-based Akonadi, thus the library API is no longer compatible with the 
old one. However the library is called libKF5AkonadiPrivate.so in Akonadi 5, 
so it's possible to co-install those two libraries. It's not possible to 
however co-install the rest of Akonadi (akonadiserver, akonadictl, ....). 

With my packager hat on, we will probably end up doing something like this in 
Fedora:

akonadi-server-15.08 (whatever is in akonadi-15.08 tarball)
akonadi-server-devel-15.08 (headers for ^^)
akonadi-15.08 (whatever is kdepimlibs, Requires: akonadi-server)
akonadi-devel-15.08 (headers for ^^)

akonadi-server-compat-libs-1.13 (libakonadiprotocolinternals.so from 
	akonadi-1.13 tarball)
akonadi-server-compat-libs-devel-1.13 (headers for ^^)
akonadi-server-compat-1.13 (the rest of akonadi-1.13 tarball, Requires: 
	akonadi-server-compat-libs, Conflicts: akonadi-server >= 15.08)
kdepimlibs-4.14 (Requires: akonadi-server-compat-libs-devel = 1.13)

Dan
> 
> > Dan
> > 
> > > Now looking at the source kdepimlibs is used for two things in kopete:
> > > 1) kpimidentities is used in the bonjour protocol as a fallback to
> > > kuser to obtain the users's name and email address for account default
> > > values (this is required, although I am not sure it should be)
> > > 2) gpgmepp is used by the crypto plugin for crypto things (this is
> > > optional, although I am not sure it should be :P)
> > > 
> > > Given that we have no kde4pimlibs source what is the intended solution
> > > to this? Cripple kopete and make bonjour optional using a patch, if so
> > > why not do that in the repo directly? Or perhaps have every distro
> > > figure out which parts of the old kdepimlibs are now defunct with
> > > akonadi moved to kf5 and package the rest for compat?
> > > 
> > > (CC'd Pali and Dan; not sure they are subbed)
> > > 
> > > HS

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- 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/release-team/attachments/20150818/fc584b23/attachment.sig>