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 [email protected] _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
