https://bugs.kde.org/show_bug.cgi?id=425272
--- Comment #2 from David Edmundson <k...@davidedmundson.co.uk> --- >install-sessions should also do whatever is needed to get DBus, PolKit, and >Kauth stuff working too. Then that stuff is transformed from a pain point into >an effortless non-issue, just like it did for making your built-from-source >Plasma desktop to appear in SDDM. DBus has two parts; user and system. IMHO the user setup isn't too hard - except for this new potential issue with /home. Personally I would solve that by installing into /opt/kde5 rather than /home especially as it's useful to test multiple users with your self-build setup. One challenge to note is that if you set up DBus and Polkit correctly to use your dev ones you have to apply something systemwide, which means any distro session also will use any dev polkit things. You can't make that change at runtime and you can't skip some root involvement. ----- For the sake of brainstorming, here's some other ideas: - We have a script/cron job to symlink some parts from your install into /etc/. Effectively what I do for my polkit and system bus . It'll break setups for people who install alongside distro KDE. - We could use a pam hook to set up the session instead of the .desktop file. At the time we run pam auth modules we know what session we will be loading. This would allow us to manipulate XDG_DATA_DIRS before the user dbus-daemon is started, which saves the session bus problem. - Some unionfs to mount a directory read-only on top of /usr at boot? Then all system stuff would just work. Would require it to be done very early in the boot before polkit. Probably a horrific idea. - We use something like checkinstall in kdesrc-build and then we can install into /usr as packages. Would work for the neon case and I'm sure there's some equivalent. -- You are receiving this mail because: You are watching all bug changes.
