kopete and kdepimlibs in apps 15.08

[Pali Rohár]

On Tuesday 18 August 2015 13:06:20 Daniel Vrátil wrote:
> 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).
> 

To prevent any other such situation, what about asking maintainers (or
on mailing list) of all kde apps? I'm sure if somebody asked me or on
kopete-devel year (or two!) ago if kdepimlibs is really required to
build kopete, answer will be there!

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

Good. But there is problem. KDE tarball packages have same name for
akonadi-server and akonadi-server-compat.

Renaming akonadi-server (v 1.13) to akonadi-server-compat is insane. If
you are introducing such new incompatibility, why not to rename KDE
tarball package e.g. yo akonadi-server2 or akonadi-server-qt5 (or any
other different name)? Something which also downstream distribution
understand that those are two different software packages, could be
installed at same time and new version is *not* drop-in-replacement for
old one.

Or if you are needed to distribute akonadi-server 15.08 version in KDE
tarball akonadi-server, cannot you add into it also old 1.13 compat
version? This will really help distribution to pack correct packages and
doing dependency magic.

(PS: I'm not akonadi developer, user or so... I just proposing general
solutions for such software problems.)

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

-- 
Pali Rohár
pali.rohar at gmail.com