[KDE/Mac] KDE4/KF5 "cohabitation"

[Ian Wadham]

Hi René and Nicolas and everybody,

On 07/01/2016, at 1:44 AM, René J.V. Bertin wrote:
> I'm sure you've noticed that I'm making progress with ports for KF5.

Yep.  Good on yer, René!

And it is nice to see that David Faure and other KDE core developers are taking an interest at last...

> KF5 is designed to allow for step-by-step migration of applications from KDE4 to KDE5, but with the underlying idea that once an application has been migrated it's the better version

For KDE applications, "better version" = "only officially released version".  There is only one
'master' branch in each KDE repository and that is the branch from which releases are made.
It is the branch where new features are developed and bugs are fixed.  A release is "maintained"
for a few months and, during that time, bug-fixes are supposed to be backported into the release.

> and users are not supposed to feel the need to keep the older version around.

In principle, a KF5 application, when first released, should have the same functionality as
the KDE4 application it replaces.  IIUC, the difference is supposed to be fewer extraneous
dependencies on libraries that used to be dragged in by using kdelibs4 and some shifting
of dependencies from KDE to Qt library classes, the most troublesome of which is the shift
from KStandardDirs to QStandardPaths… ;-)

Porting to Frameworks and Qt 5 is done on a 'frameworks' branch of the app's repository and
finally merged into 'master'.  If that work is done quickly, there should be few large changes
on the 'master' branch during the porting work.

In practice, of course, porting work does get held up, sometimes for months, and it is possible
(but unlikely?) for a lot of work to occur outside the 'frameworks' branch while it is open.

I have just been assisting a guy in porting KMahjongg, a KDE game.  It had a huge, years-old
branch that that ported some of the code from KDE 3 to KDE 4, but had never been merged
into 'master.…  That branch and 'master' contained a dozen or more bug fixes and there were
graphics glitches in the KDE 3-to-4 port that had to be fixed.  So yes, in this case the KF5
version, to be released in April, will definitely be "better".

Hopefully, that kind of mess will be the exception rather the the rule… but there are an awful
lot of unmaintained applications in the KDE code base these days.  The workforce is a small
fraction of the 500 or so developers KDE 4 had 5-8 years ago… :-(

> I have some issues with that premise

Having said the above, I agree entirely, René.  I have, and always have had, issues with the
idea that a newer version is automatically better...

I have experienced many regressive releases of KDE apps, some due to apps changes and
some due to library changes --- even of my own apps, in cases where I had made no change.

Also, if there is ever a KF5 port of KMyMoney, I would hesitate to entrust all my finances to it
on day one… ;-) … with all due respect to Marko and the KMyMoney developers.

> and know of nothing in MacPorts that would make it the default behaviour to force a choice between either KDE4 or KF5 versions of an application (fortunately, with all the inter-dependencies).

One hope I have is that MacPorts will help us avoid the day when KDE 4 and Qt 4 libraries are
no longer released and apps that have not yet been ported to KF5 will just quietly disappear… :-(

On Linux, we lost a quite a few good KDE programs in the transition from KDE 3 to KDE 4.

> KF5 software doesn't leave a lot of leeway to configure it such that it won't clash with KDE4 versions of the same, in line with said premise. Fortunately most of the time the conflicts are limited to non-crucial things in ${prefix}/share, usually even things that were not changed w.r.t. their KDE4 version. So most of the time, the +kde4compat variant of a KF5 ports just omits files that are already installed by the KDE4 version of the port.

The strategy on Linux is that an app is either KDE4 or KF5, no overlap.  Apps and the Frameworks
library are released separately, on different schedules.  See https://techbase.kde.org/Schedules …

Apps are released in KDE Applications YY.MM releases every four months and can be a mix of
KDE 4 and KF5 apps.  On Linux, KDE 4 libraries, Frameworks, Qt 4 and Qt 5 can co-exist, but
that is all.  Each app is either KDE 4 or KF5.

It would be very nice if MacPorts could be more flexible than that.

> There are however certain modifications that have to be made to (certain) KDE4 ports:
> 
> - The most frequent conflict occurs at the level of headerfiles. This can be avoided very easily by building KDELibs4 with -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers under include/KDE4 but also records the path in a cmake module, so that it is inherited by all dependents.
> The nice thing is that this change doesn't break binary compatibility, so I have set it unconditionally in my KDE4 PortGroup; it gets applied when a port is rebuilt.
> 
> - CMake modules are still an issue; I haven't yet found out a good way to install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving the files to a place outside the standard cmake include path (requiring CMAKE_PREFIX_PATH to be set) ... but that will only protect against file name clashes and against KF5 ports picking up cmake modules from KDE4 software :-/
> 
> - the biggest issue is with the libraries of some ports, e.g. kompare and libkomparediff2. While the runtime libraries (lib*.x[.y].dylib) are usually distinguishable thanks to the version numbers, the linktime libraries (lib*.dylib) aren't always. Or the developers had the brilliant idea to use case, which means I won't always catch potential clashes because I use a case-sensitive filesystem.
> Either way, I am fine-tuning a mechanism to be used with +kf5compat, a set of procedures where the 1st sets -DCMAKE_INSTALL_PREFIX=${kde4.legacy_prefix} (${prefix}/libexec/kde4-legacy) and the optional 2nd procedure moves a number of appropriate things back into ${prefix}. When you don't call that 2nd procedure you end up with an installation that requires dependents to be built with kf5compat too; fortunately it is enough to set CMAKE_INSTALL_PREFIX in identical fashion to make the build work in that case.
> I've had to patch port:kdelibs4 to install a symlink (${kde4.legacy_prefix}/share -> ${prefix}/share) in order for this to work perfectly, but everything indeed seems to work just fine like that, including full transparency at runtime.
> 
> I haven't had to rebuild a single KDE4 port because one of its dependencies was rebuilt using the hacks above, but that may just mean that I have yet to encounter a problem port.
> 
> This is where I could use help from others who have KDE4 ports installed, the more complicated the dependencies the better.
> There is only so much time I can devote to checking existing KDE4 ports (which do not yet have a KF5 version) against the compatibility changes I've been making, in addition to the time I spend developing KF5 ports.

I'd like to help, as long as we are just talking about KDE 4 and Qt 4 ports…

> Help could come in 2 or 3 forms:
> - install my KDE4 portgroup and port:kdelibs4. Check what effect that has on your existing KDE4 ports; should be transparent. Check if that's still the case after rebuilding them (supposing that works out OK). One set of ports that I haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because those are a bit too crucial for me…
> 
> - idem, but also build the ports from my repository that have a +kf5compat variant, with that variant selected. Again you should not notice any change.

Can do, but KMyMoney4 is the only complex KDE port I use…  OTOH, I have
several KDE development setups, based on kdesrc-build, so they could be
an extra test.

> - provide me with a reasonably fast and reasonably close-by (from France) VM on which I experiment a bit more freely than on my own, single system. (I'm a bit too late to leave hardware suggestions for Santa so I'll keep it at that ;))

Due to continental drift (aka plate tectonics) I cannot help with that… :-)

Cheers, Ian W.