On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote: > On Fri, Apr 3, 2020 at 2:18 PM Jan Pazdziora <jpazdziora@xxxxxxxxxx> wrote: > > > The dependency chain from @core to gtk3 and fonts actually goes from > > gnupg2, required by dnf, which recommends pinentry, which requires > > libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which > > requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which > > requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit). > > > > I added the libsecret -> gnome-keyring recommends due to > https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best > to revert this change and move the gnome-keyring recommends to geary > instead. > > Any thoughts? > If geary cannot work without a libsecret server, then geary should hard-require one of them. It seems that libsecret library is perfectly fine without a server (although it makes the client pointless) as pinentry demonstrates. I understand that the same issue can repeat with any libsecret application that does not survive libsecret failure and centerilizing the dependendency at one place sounds right. But it indeed looks like the failure is in the application. Maybe libsecret spec could provide an empty libsecret-never-fail subpackage that would hard-require a libsecret server and the applications like geary would require that subpackage. (Alternatively libsecret-devel could provide a RPM macro that the applications use to add a direct dependency on a server.) But this abstractions is quite academic provided the only libsecret server in Fedora is gnome-keyring. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx