libksysguard from Plasma 5.2 conflicts with libksysguard from kde-workspace. For example, both have /usr/lib/libprocessui.so file (resulting "devel(libprocessui)" RPM package Provides), as well as many other conflicting files. As it's a Qt5/KF5-based library, it makes sense to rename it with KF5 prefix, like libkscreen from Plasma 5 has (libKF5Screen.so). The same applies to cmake, includes etc. And it also makes sense to rename kauth stuff from org.kde.ksysguard.* to org.kde.ksysguard5.*. See the attached patch from OpenSUSE build ( http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Frameworks5/openSUSE_Tumbleweed/src/ ). This will help downstream to keep both KDE4 and Plasma 5 in repositories. Reproducible: Always
Created attachment 91311 [details] Patch from OpenSUSE that renames kauth stuff in libksysguard
I do not really see the need. We communicated for at least a year now that Plasma 4 and 5 are not co-installable and no applications should use the libraries used by ksysguard.
(In reply to Martin Gräßlin from comment #2) > I do not really see the need. We communicated for at least a year now that > Plasma 4 and 5 are not co-installable And there's nothing good in it. It's a bug, not a feature. Unless it's a political decision, not technical. > and no applications should use the libraries used by ksysguard. I can add Conflicts to RPM packages to avoid co-installing 4 and 5. But adding Requires/Provides filters to avoid "devel(libprocessui)" (= "/usr/lib/libprocessui.so" file) etc Requires/Provides is too much hacks already. On the other hand, if no applications should use these libraries, I can do the job downstream.
What app is using it?
(In reply to Pulfer from comment #3) > On the other hand, if no applications should use these libraries, I can do > the job downstream. well it was a workspace library which means that we never gave ABI guarantees for it. This IMHO implies that it also doesn't give guarantees for co-installability.
(In reply to David Edmundson from comment #4) > What app is using it? At least these apps used KDE4 version of ksysguard libraries: kdebase4-workspace kdevelop4 knemo plasma-applet-fancytasks sentinella Not many.
In data venerdì 27 febbraio 2015 09:49:54, Pulfer ha scritto: > kdebase4-workspace FWIW: in openSUSE we have split the libraries from the workspace, so that installing a 5.x workspace will not cause conflicts and possibly removals of packages like kdevelop.
(In reply to Pulfer from comment #6) > At least these apps used KDE4 version of ksysguard libraries: > > kdebase4-workspace > kdevelop4 > knemo > plasma-applet-fancytasks > sentinella The only non-workspace application of those is kdevelop4. All other should not/cannot be used in a Plasma 5 session.
Created attachment 91314 [details] Quick patch to rename libksgrd to libKF5ksgrd I'll likely go this way with my downstream Plasma 5 packaging. Because I really see now reason to have any file conflicts between KDE4 and Plasma 5 packages.
(In reply to Pulfer from comment #9) > Created attachment 91314 [details] > Quick patch to rename libksgrd to libKF5ksgrd this renaming is wrong as it's not a frameworks library and also not planned to become one. Thus it should use the KF5 prefix.
(In reply to Martin Gräßlin from comment #10) > (In reply to Pulfer from comment #9) > > Created attachment 91314 [details] > > Quick patch to rename libksgrd to libKF5ksgrd > > this renaming is wrong as it's not a frameworks library and also not planned > to become one. Thus it should use the KF5 prefix. Can be libksgrd5.so with /usr/include/ksysguard5 then. Anything but file conflicts with kde-frameworks.
(In reply to Pulfer from comment #11) > Can be libksgrd5.so with /usr/include/ksysguard5 then. Anything but file > conflicts with kde-frameworks. I really do not understand the need. From what Luca wrote the library can be co-installed on openSUSE. Also the so-version changed.
yeah, we have the helper splited as a package on openSUSE, so lib can be coinstalled (ftr. the patch you pasted is not 'an openSUSE' patch)
(In reply to Martin Gräßlin from comment #12) > I really do not understand the need. From what Luca wrote the library can be > co-installed on openSUSE. Also the so-version changed. The need is to avoid any file conflicts. What's the need to have them if it's easy to avoid? Why should translations from libksysguard force users to remove kde-l10n package (.po conflicts), development files from libksysguard should force to remove kde-workspace-devel package (.so conflicts) etc. There's nothing hard in avoiding this, I really don't understand the need to keep conflicts.
RPM package (spec and patches) that doesn't conflict with KDE4 stuff: https://abf.io/import/libksysguard ksysguard from Plasma 5.2.1 build fine with this package installed.
Hrvoje Senjan, BTW, how do you deal with translation file conflicts in OpenSUSE's KDE packages? kde-l10n upstream tarball contains translations for both Applications 4 & 5 and Workspace 4. And translation files from Plasma 5 packages conflict with Workspace 4 files from kde-l10n. How users should install Plasma 5 and Applications 4 & 5 translations?
And it looks like RPM in OpenSUSE doesn't generate devel(libname) Provides/Requires for libraries. So no surprise you don't see what's wrong with having Provides/Requires collision because of .so files with same names in KDE 4 and Plasma 5 development packages...
Sorry to close this bug, but we do not support installing Plasma 4 and 5 alongside.