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 | [email protected] IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
