Baloo's runtime bits are backwards compatible, the libraries co-installable. A minimal USE flag would work to remove the runtime bits. baloo:4 configures, but does not compile against kfilemetadata:5, it seems to run fine with kfilemetadata:5 installed, though. The steps that I took to install baloo and kilemetadata in version 4 and version 5 alongside are: Install baloo:5 and kfilemetadata:5 normally (probably best to make ebuilds that remove the blockers). Then remove kfilemetadata:5 and install kfilemetadata:4. Now compile (minimal versions of) baloo and, if needed, baloo-widgets, since either will fail with an error about Qt5 not being found (yes, Qt5, not Qt4). I then made a minimal version of kfilemetadata:4, mostly to satisfy dependencies in portage, although I'm not sure if it's really needed. Compiling baloo with a minimal kfilemetadata won't work because USE=minimal has to remove all the header files. The only other KDE4 package that I've tried to compile against kfilemetadata:5 is dolphin and that works fine. I just don't know if that dependency is handles opportunistically by the configure system. All other KDE4 packages that I've tried compiled against minimal baloo without a problem. This is most likely a KDE bug. I just wanted to rule out any possibility of it being gentoo-specific, since on the KDE forums I was told that baloo:4 and baloo:5 where meant to run alongside. Either way, Gentoo should track this, since it affects us. Reproducible: Always
Created attachment 379166 [details] baloo-4.13.2 with minimal USE flag
Created attachment 379168 [details] kfilemetadata-4.13.2 with minimal USE flag
Created attachment 379170 [details] baloo-4.12.3 build.log with kfilemetadata:5
Sorry, I was wrong. Dolphin fails as well.
The kfilemetadata part should be fixed upstream shortly: https://git.reviewboard.kde.org/r/118670/
kfilemetadata is fixed upstream and blocker removed in overlay. We should consult with upstream how they intend baloo to be handled.
baloo has minimal USE flag now.
