OK, some more technical stuff.
I have found a better, more elegant solution to the KDE problem.
The entire reason that the KDE
x11/plasma6-plasma-desktop port can't be installed alongside xlibre-server is due to its RUNTIME dependency on X.Org drivers:
x11-drivers/xf86-input-libinput
and
x11-drivers/xf86-input-evdev
Now why is there a dependency on these two drivers in the first place?
It is because of the diabolical scheme that was put into place for communicating default values of properties associated with xf86-input-* drivers to the input configuration utilities present in desktop environments.
Instead of a simple, humble text file, the xf86 input drivers generate a C header and a pkgconf file that is then depended on and included by a DE's input configuration tool, and it in turn sets its default values based on the list of "#define"s in these header files.
The things to note:
- This is done for just setting the default values of these configuration utilities.
- All of this is happening during compile time.
The libinput driver is basically the only ** driver whose exported properties are depended on by other ports. Moreover, those properties are based on the defaults of libinput itself.
So, by letting these ports just depend on xf86-input-libinput during build time instead of xlibre-xf86-input-libinput, we are not breaking anything for XLibre users because the exported properties by these drivers are based on the shared libinput library's defaults and are the same between XLibre and X.Org. (Even if we were to break anything, it would just make the default values of the GUI configuration utilities for XLibre users have different values).
The problem that we are currently facing is that the KDE Plasma 6 Desktop port not only depends on these ports in build time but also in run time, and I have found this runtime dependency to be unnecessary. I have not found anything in x11/plasma6-plasma-desktop that requires a hard dependency on these drives in runtime. I have even searched some of the Linux package repos, and they all listed these 2 drivers as build-time dependencies of plasma-desktop:
https://github.com/void-linux/void-packages/blob/master/srcpkgs/plasma-desktop/template
https://archlinux.org/packages/extra/x86_64/plasma-desktop/
By just removing the runtime dependency of
x11/plasma6-plasma-desktop on these two drivers and keeping their build-time dependencies, we can solve this issue without needing to use any FLAVORs.
So just a ~2 line diff:
Diff:
diff --git a/x11/plasma6-plasma-desktop/Makefile b/x11/plasma6-plasma-desktop/Makefile
--- a/x11/plasma6-plasma-desktop/Makefile
+++ b/x11/plasma6-plasma-desktop/Makefile
@@ -19,9 +19,7 @@
LIB_DEPENDS= libcanberra.so:audio/libcanberra \
libxkbcommon.so:x11/libxkbcommon \
libxkbfile.so:x11/libxkbfile \
RUN_DEPENDS= noto-emoji>0:x11-fonts/noto-emoji \
- xdg-user-dir:devel/xdg-user-dirs \
- xf86-input-evdev>0:x11-drivers/xf86-input-evdev \
- xf86-input-libinput>0:x11-drivers/xf86-input-libinput
+ xdg-user-dir:devel/xdg-user-dirs
USES= cmake gettext gl gnome kde:6 pkgconfig python qt:6 tar:xz xorg
USE_GL= gl opengl
** The evdev input driver is also depended by plasma-desktop but it has been removed:
It's not necessary to access it directly anymore, now that we only expose settings for libinput.
github.com
.
(evdev) to the new one (libinput) and there was no reason to left to support the former.