https://bugs.kde.org/show_bug.cgi?id=509680
--- Comment #16 from michaelk83 <[email protected]> --- Gemini tells me that the unwanted dependency is more likely to be in xdg-destktop-portal itself, rather than in xdg-destktop-portal-kde, mostly likely xdg-destktop-portal trying to probe all available interfaces when it's first accessed. Having xdg-destktop-portal lazy-load the Secret portal would depend on upstream, but we came up with a few solutions that could be implemented in ksecretd. They rely on detecting and aborting the premature activation: The 1st option is to try to detect if activation occurs during early session startup, for example by checking if org.kde.KScreen or org.kde.kded6 have launched yet (with G_DBUS_CALL_FLAGS_NO_AUTO_START or equivalent). If the session is not ready, and --pam-login is not present, abort the early activation (or at least don't show an unlock prompt). The 2nd option is to check if kwallet-pam is configured. If it is, then specifically wait for the --pam-login argument. A 3rd option was to differentiate generic DBus probing calls from actual method calls, and refuse to fully start on general probing. But since the DBus interface class is auto-generated, this is probably not practical. Finally, the 4th option is to modify the DBus service activation file for org.freedesktop.impl.portal.desktop.kwallet to delegate actual activation to SystemD. Then the SystemD unit file can specify Requires=plasma-workspace.target and After=plasma-workspace.target, to block activation until the workspace is ready (by which point, kwallet-pam should have properly run). -- You are receiving this mail because: You are watching all bug changes.
