It's not supposed to.
(In reply to Cedric from comment #0) > It's not supposed to. Actually, it's both right and wrong. It's actually IIRC something I pointed out on #gentoo-desktop back in 3.6 cycle, based on NEWS in gnome-keyring. Namely that PDEPEND in gnome-keyring should have been changed from 'gnome-base/libgnome-keyring' to '|| ( gnome-base/libgnome-keyring app-crypt/libsecret) '. But chances are that putting the dep in app-crypt/libsecret instead is simply wrong.
libsecret is completely useless and non-functional unless it has access to a dbus service which implements the fdo Secret Service API (see http://standards.freedesktop.org/secret-service/). I know of two projects providing an implementation of this service: gnome-keyring-3.x and ksecretsservice. Since gnome-keyring is in portage and ksecretsservice is not, the libsecret ebuild currently has a runtime dependency on gnome-keyring only. Obviously this will be changed after ksecretsservice is in the main portage tree. If there is another implementation of Secret Service API in portage, please let us know, and we will change the dependency.
(In reply to Rafał Mużyło from comment #1) > Namely that PDEPEND in gnome-keyring should have been changed from > 'gnome-base/libgnome-keyring' to '|| ( gnome-base/libgnome-keyring > app-crypt/libsecret) '. As far as I can tell, that PDEPEND is historical cruft from the time when gnome-keyring was split into libgnome-keyring and gnome-keyring proper, and as a quick-and-dirty workaround, it was decided to add a PDEPEND instead of properly fixing the dependencies in gnome-keyring using packages. It ought to be removed completely, not expanded.
What exactly is "completely useless and non-functional"? If its uselessness consists of simply not doing its job, I don't see a problem with that. I noticed this dependency in WebkitGTK+. I don't care for storing passwords, but WebkitGTK+ does not allow to disable the libsecret dependency. I don't think every "frontend", so to speak, to some service needs an RDEPEND on the service. The user should be free to install whatever (or no) backend they prefer. A "not working" frontend is still a "working frontend", as long as it does not causes errors. In other words: Libsecret without a working secret-service backend is a perfectly reasonable choice. I still think the dependency should be removed.
(In reply to Alexandre Rostovtsev from comment #3) > (In reply to Rafał Mużyło from comment #1) > > Namely that PDEPEND in gnome-keyring should have been changed from > > 'gnome-base/libgnome-keyring' to '|| ( gnome-base/libgnome-keyring > > app-crypt/libsecret) '. > > As far as I can tell, that PDEPEND is historical cruft from the time when > gnome-keyring was split into libgnome-keyring and gnome-keyring proper, and > as a quick-and-dirty workaround, it was decided to add a PDEPEND instead of > properly fixing the dependencies in gnome-keyring using packages. > > It ought to be removed completely, not expanded. In such case, perhaps it's libsecret, that should PDEPEND on keyring ? Just like in polkit case, where gui frontends are PDEPENDs too.
(In reply to Rafał Mużyło from comment #5) > In such case, perhaps it's libsecret, that should PDEPEND on keyring ? > Just like in polkit case, where gui frontends are PDEPENDs too. PDEPENDs are only needed to break circular dependencies. In this case, there is no circular dependency: libsecret needs gnome-keyring to function, but gnome-keyring does not need libsecret. (In reply to Cedric from comment #4) > I noticed this dependency in WebkitGTK+. I don't care for storing passwords, > but WebkitGTK+ does not allow to disable the libsecret dependency. I see. So to save a little bit of disk space, you really want to be able to install a known-broken configuration: a library that cannot possibly work :/ I would suggest that your goal (minimizing disk space) would be better met by not installing any non-working libraries in the first place. In other words, by making libsecret optional in webkit-gtk.
As I put some time ago in ebuild about the reasons why webkit-gtk upstream decided to let it optional (keyring support wasn't): # * libsecret dep was made optional for compatibility with Windows, not sure # if we really want to make credential storage optional
(In reply to Pacho Ramos from comment #7) Not all webkit-gtk users need password storage. For example, there are applications like dev-util/devhelp that embed a webkit-gtk widget just to render local html documentation files; they will never need to use password protection. And there even are use cases where you may want to explicitly disable password storage, like a public information kiosk with a web browser.
(In reply to Alexandre Rostovtsev from comment #6) > I see. So to save a little bit of disk space, you really want to be able to > install a known-broken configuration: a library that cannot possibly work :/ > > I would suggest that your goal (minimizing disk space) would be better met > by not installing any non-working libraries in the first place. In other > words, by making libsecret optional in webkit-gtk. Let me refer you to [1] regarding "disk space". My concern is with keeping a clean system and as few unneeded packages (and therefore files) as possible. Making libsecret optional in webkit-gtk is a possibility, however, I don't deem it any more or less valid than making gnome-keyring optional in libsecret. The rational is the same in both cases: I don't want password storage, thus, I don't need any software which stores passwords. If webkit (through libsecret) has the mere theoretical capability of interfacing to a password storage, that doesn't necessarily imply that there *is* such a password storage. [1] https://forums.gentoo.org/viewtopic-t-956072-start-0-postdays-0-postorder-asc-highlight-.html
Will add a flag then (but for next bump, to prevent rebuild of this beast :S)
fixed in 2.0.4
*** Bug 507640 has been marked as a duplicate of this bug. ***
The comment in the libsecret ebuild still refers to this ticket[1], even though it has changed its statement since, and was closed. There's an open ticket about removing gnome-keyring dependency from libsecret here: https://bugs.gentoo.org/705132 [1] https://github.com/gentoo/gentoo/blob/26db2c563a6cfc77a09252373e460d9414264ff0/app-crypt/libsecret/libsecret-0.20.4.ebuild#L31
