[kdepim-users] Fwd: akonadi 4 & 5 not coinstallable !

[René J.V. Bertin]

On Friday November 27 2015 08:35:25 Daniel Vrátil wrote:

Hi,

>> Wouldn't that have justified changing names all over, so that compatibility
>> questions wouldn't have come up (or less likely so)?
>
>Not really. We just percieve it as an update. You don't have kate5.2, kate5.3 
>etc. just so that you can coinstall two updates...

No, but you do have kate vs kate5, or at least it looks like you could by simply renaming the executable as the kpart on which it's based won't bite the KDE4 version.

>Does Digikam actually need Akonadi? If it only needs some of the kdepimlibs, 

I'd hope not (except as a weak runtime dep), and guess that applies for other dependents of kdepimlibs too, like kmymoney.

>patching Akonadi server from akonadi so that only the shared library is 
>compiled).

That would indeed be an option if that's "all it takes". I suppose I'd also have to strip the corresponding .desktop files and the ones for DBus, to avoid confusion at that level? If so, I may come back with a specific question once I get there, to check I'm doing things properly.

That can even be done at the packaging level if not doable by excluding subdirectories from CMake. I've already added a "kde4compat" variant to the few Frameworks that insist on installing files with the same name in the same place as their KDE4 counterparts (sometimes exactly the same file). Those were only items of little importance though, a couple of icons and a directory with HTML documentation.

>In pure theory you can alternate "Akonadi 4" and "Akonadi 5" on top of the 
>same database. In practice you don't want to do it.

No, I bet. I've followed the same guideline with KDE PIM 4.14/git vs. 4.13.3 ...

> Even if we make it co-installable, people will get the impression that they
> can run both at the same time - which they can't - and would mess up they
> data and spam us with bug reports about it.

Not really the correct usage of the S term, but yeah. I have never looked into how akonadi gets started if not done manually, so I don't know how feasible it would have been to add a "some other version is already running, aborting" check at startup that works retro-actively, i.e. wouldn't require pushing an update to KDE4 users. Though I guess that the vast majority simply use what their distribution provides.

All this does make it a bit easier to understand why (K)Ubuntu stopped their Project Neon5, and why apparently no one has stepped up to provide a way to install KF5 in parallel on a KDE4-based LTS system like my Linux rig. (I can't speak for Gentoo Prefix or pkgsrc as they don't support "Debuntu".)
 
> >"Akonadi 4", there should not be a need to have both (yes, we unfortunately 
>underestimated the amount of 3rd party apps directly or indirectly depending 
>on Akonadi).

What, only the Akonadi users knew it's kind of like the octopus metaphor for the mob boss? ;)

>I switched to v5 immediatelly after we did the basic v4->v5 port and used it 
>since, I never ran v4 with v5 in parallel as "development" version.

Let me guess, that initial porting effort was done in a VM or on a separate system that didn't have the KDE4 version installed?
I sadly do not currently have the resources to follow that approach (already almost cost me everything under /Applications because of an issue in Qt's QStandardPaths which I discovered in the wild). I do have a Linux system on which I'm using the same build/packaging mechanism to install KF5 in a separate prefix so there I could install all of akonadi as long as that won't confuse DBus (because I did *append* /opt/local/share to XDG_DATA_DIRS). But it's an ageing netbook that's hardly usable for serious development (I think it took about 1h to build kdelibs4support) :(

R.
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users