gentoo/kde overlay commit 15f73a08b0b3f5e9ed130c7b4ce1fb5811236793 changed the kde-cli-tools RDEP to kde-cli-tools[kdesu]. That conflicts with my no-GUI superuser policy. All tasks requiring superuser are done at CLI/TUI here, and I neither allow GUI superuser tasks nor tolerate installation of tools that would encourage/easy-enable them. Of course that means no polkit and no kdesu framework allowed. (CLI login too, FWIW, so automated local-login-related dev-perms changes via udev/systemd-logind don't violate the policy either.) That commit would upend that policy, but despite the no-specific-pointer mention of kdesu being "required" by ksmserver, I've yet to see any evidence of such requirement in either what I'm running now or in upstream plasma-workspace git log from what I'm running now to current HEAD. Without a pointer to the specifics and having experienced no problems with it to date, I /suspect/ it only "requires" kdesu for tasks like restarting su dolphin sessions and the like as part of setting up the GUI session, but if such su dophin sessions are never run in the first place due to policy and lack of the GUI tools they can't need restarted, so I'll never run into the issue meaning it shouldn't be "required" here after all. Unfortunately, because it's a USE-dep on a package I already have installed as a generic dep for plasma-workspace and other packages, I can't just null-pkg kde-cli-tools (as I do with e.g. udisks), which means if the plasma-workspace RDEP isn't put under a USE flag I'll have to patch it (and carry and maintain the patch) locally. Fortunately I have maintained the /etc/portage/patches alike patches.ebuild functionality I hacked up during the gentoo/kde kde4 USE=no-semanticdesktop loss era so it's doable (and way simple compared to that), but if I can convince my upstream to make it a USE flag dep I can avoid that. =:^) I'd suggest IUSE=+kdesu to keep the new and now current default.
That's a problem, since Portage does not support optional RDEPENDs. https://invent.kde.org/plasma/plasma-workspace/-/blob/master/ksmserver/server.cpp#L142 At this point in time, ksmserver is unconditionally installed by plasma-workspace, although I suspect it serves no purpose in Wayland sessions, and *may* be possible to be made optional by means of existing -DWITH_X11 cmake arg. Upstream says "Building without is experimental" right now and last time I tried (albeit a long time ago), it was bound to fail.
Enabling kdesu use flag for kde-cli-tools pulls in kdesu-gui which itself hard depends on sys-apps/dbus[X]. kdesu-gui itself has a iuse X, but this is only used for kwindowsystem and -DWITH_X11, but not for sys-apps/dbus. I haven't found any hint that dbus with X enabled is required by kdesu. I looked into the code in https://invent.kde.org/plasma/kde-cli-tools/-/tree/master/kdesu and according to CMakeLists.txt there is no requirement for DBus, also the .cpp and .h files do not show any direct dbus includes or function calls. Maybe I missed something.. I'm running wayland only as much as possible and trying to get rid of X and this change instead adds a new dep on X. Would it be possible to revert that change and just add an einfo or optfeature if dbus is really required? I've never had any issue before without kdesu enabled.
(In reply to Steffen Hau from comment #2) > I'm running wayland only as much as possible and trying to get rid of X and > this change instead adds a new dep on X. Would it be possible to revert that > change and just add an einfo or optfeature if dbus is really required? I've > never had any issue before without kdesu enabled. As I said, as long as plasma-workspace itself installs components unconditionally that use kdesu we have to provide it as well. optfeature is only for "weak" optional runtime dependencies. Of course if someone starts working on testing plasma-workspace WITH_X11 option I mentioned above and submits some upstream MR(s) that get accepted, we can put kdesu away behind an X flag. (In reply to Steffen Hau from comment #2) > Enabling kdesu use flag for kde-cli-tools pulls in kdesu-gui which itself > hard depends on sys-apps/dbus[X]. kdesu-gui itself has a iuse X, but this is > only used for kwindowsystem and -DWITH_X11, but not for sys-apps/dbus. I > haven't found any hint that dbus with X enabled is required by kdesu. I > looked into the code in > https://invent.kde.org/plasma/kde-cli-tools/-/tree/master/kdesu and > according to CMakeLists.txt there is no requirement for DBus, also the .cpp > and .h files do not show any direct dbus includes or function calls. Maybe I > missed something.. The alternative being if we can confirm this ^. Will have to take a look if there was a reason cited for adding the dependency (previously, there was a REQUIRED_USE in kde-cli-tools for USE=kdesu hard-requiring USE=X, and that's where the dbus[X] RDEPEND is coming from) of if it has since been rendered obsolete by upstream developments (so let's look through their git history). But that all takes time. ;)
After trying myself, I can confirm the observations in the linked bug are still accurate: kdesu relies on sys-apps/dbus[X] at runtime even in Wayland sessions. kde-plasma/plasma-workspace:6 at this point still depends on plenty of X libs, as already mentioned, so you shouldn't lose sleep over one more. If you do, still, however, or really want to enforce a no-GUI superuser policy, which I can understand, there always is package.provided at your service. Real help on getting X depending components optional in upstream repositories would be much appreciated, though.
Gentoo/kde overlay ea5fc01cfd736fca738b9b893cc9e0ee6ebf913f is a reasonable compromise for me. That commit switches plasma-workspace's rdep from kde-cli-tools use-based to a dedicated split-out kdesu-gui package, which allows me to less-invasively null-pkg[1] the dedicated split-out package instead of having to patch out plasma-workspace's previous USE-dep on kde-cli-tools, since I wanted/needed the more general kde-cli-tools, just not the part that was kdesu USE-flag controlled but is now split out into kdesu-gui. (I do the same with for instance kde-plasma/xdg-desktop-portal-kde, an rdep-only required by kde-plasma/plasma-integration. Because I don't plan to ever use the xdg-desktop-portal functionality at all and both best security practices (can't exploit what's not there) and the need to keep it upgraded if installed strongly encourage keeping unnecessary/unused packages off the system, with xdg-desktop-portal-kde an otherwise unrequired rdep-only, I can simply null-pkg it.) --- [1] null-pkg: an empty package only installed to fill the dep, with no deps of its own and its only installed files being the ones in the pkg-db. Basically package.provided but providing more control over USE flags, keywords, etc. Years ago package.provided was supposed to be deprecated as it allow USE flag control, etc. Don't know what happened to that but that's why all my entries of that type are null-pkgs, not package.provided entries.
