kopete and kdepimlibs in apps 15.08

Tue Aug 18 12:16:13 UTC 2015

On Tuesday, August 18, 2015 1:25:56 PM CEST you wrote:
> 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!

What is the plan with Kopete? Are you guys switching to KF5 in 15.12?

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

Does not matter. Akonadi 1.13 tarball has been released a year or so ago and 
most distributions already ship it, so it's just about renaming the actual 
package (if they decide to go with the solution I outlined). There won't be 
any new releases of Qt4-based Akonadi, so the tarball name conflict is not a 
problem. Similar like with many distributions shipping compat versions of 
libpng.

> 
> Renaming akonadi-server (v 1.13) to akonadi-server-compat is insane. 

Not insane at all, it's a very normal practice in distribution packaging. 

> If you are introducing such new incompatibility

akonadi-15.08 is a new *major* release, so there are new dependencies and it's 
not compatible with Qt 4 versions.

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

Well that's the thing, those two packages are not supposed to be installed at 
the same time because you cannot have two different Akonadi server running at 
the same time, it's just a new version of the same thing, hence the same name.

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

Yes, that might be a (longterm) solution if we need to make it possible to 
build kdepimlibs4 for years to come, but I sincerely hope that's not the case 
and that kdepimlibs4 will die very soon.

Other option is for distrubutions to simply patch-out Akonadi and related 
dependencies from kdepimlibs4, thus only shipping KAbc, KCalCore etc.

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

-- 
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/e10dc756/attachment.sig>