Description of problem: On environment without package gnome-keyring (e.g. Basic Desktop or Minimal Install) execution of Geary ends with error: ![???] 21:11:42 0.144103 geary: geary-controller.vala:349: Error opening libsecret: The name is not activatable Trace/breakpoint trap (core dumped) After installing package gnome-keyring, Geary runs OK. Geary also runs after uninstalling gnome-package (when I install gnome-keyring before). Not sure if it's problem with Geary package or libsecret, maybe gnome-keyring can be replaced with another package. At any rate, there can be some package in dependency list to run Geary properly after pcakage installation. Version-Release number of selected component (if applicable): geary 3.32.1 Steps to Reproduce: 1. Install Fedora 30 (netinst), in Software Selection select Basic Desktop 2. Run terminal, install Geary with "sudo dnf install geary" 3. Run Geary (e.g. from terminal)
geary-3.32.2-1.fc30.x86_64 depends on 'libsecret-1.so.0()(64bit)', so maybe that's indeed a libsecret issue. Re-assigning, maybe the libsecret maintainers can comment.
libsecret can work with different backends. It doesn't talk to gnome-keyring specifically but instead uses the freedesktop Secret Service DBus API: https://specifications.freedesktop.org/secret-service/ I suspect KDE is implementing this API as well. https://community.kde.org/KDE_Utils/ksecretsservice seems to say so if I understand that right. If the above is right, I think it would be wrong for the libsecret package to require gnome-keyring, as it can also work with the KDE secret service implementation.
Nonetheless, we should have a mechanism to ensure that one provider is installed alongside libsecret. I am not sure however, which mechanism that would be - rich dependencies, comps, ...?
I'd say it has to be a package level dependency. Comps seems like a wrong layer.
I looked around a bit to see what's actually packaged for Fedora and failed to find any other implementations of org.freedesktop.Secrets API beyond gnome-keyring. https://community.kde.org/KDE_Utils/ksecretsservice appears to not be packaged for Fedora. If it were, I think we should be able to do in libsecret.spec: Recommends: (gnome-keyring or ksecretsservice) Suggests: gnome-keyring ... which should have the effect of preferring gnome-keyring, but also if ksecretsservice is already installed, satisfy the dep. Anyway, since we don't have ksecretsservice, I went ahead and just added a plain "Recommends: gnome-keyring" to libsecret in https://src.fedoraproject.org/rpms/libsecret/c/4976bb03f9ee7c767eda779ed0937575927d0525