kopete and kdepimlibs in apps 15.08

Tue Aug 18 12:35:35 UTC 2015

On Tuesday, August 18, 2015 2:28:24 PM CEST Pali Rohár wrote:
<snip>
> > > 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?
> 
> Basically I do not have time for doing this switch. But if there will be
> all needed patches, I can find time to review and merge them.
> 
> Currently R.Harish Navnit is working on KF5 port as part of his GSoC
> work. So question about plan and state is for him.
> 
> I would say that rewriting kopete code to work without KABC will not be
> simple.

No need, we just renamed KABC to KContacts in 15.08, so simple regexp to 
change namespace and includes is all you need to do.

> > > > > 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.
> 
> For me it looks like this contains too much work for repackaging,
> retesting, etc... that everything works...
> 
> > > 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.
>
> I understood, that you can have installed both version of client
> libraries.

It was never intended by us, but yes, it's possible now.  It's no possible for 
KDE4 applications to talk to KF5 Akonadi server through kdepimlibs4 though and 
vice verse.

> 
> > > 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.
> 
> One thing is what you and other developers hope and another is reality.
> I saw this once with KDE4...
> 
> > Other option is for distrubutions to simply patch-out Akonadi and related
> > dependencies from kdepimlibs4, thus only shipping KAbc, KCalCore etc.
> 
> This is not easy for non-akonadi developers. It would have been great if
> KDE developers though about it before...
> 
> > > (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/d597ebd6/attachment-0001.sig>