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? 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? > > 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.ro...@gmail.com _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
