GDBusProxy not uncached on gnome-keyring-daemon replace
Maybe this is related to #9, but also maybe not. Users claim that a replacement of org.freedesktop.secrets service usually means errors. The #9 claims the libsecret can survive lost connections, but it's not completely true. This is the proof. The first line contains a comment with a command to compile and run this test program. It:
- prints what gnome-keyring-daemon process is running
- runs a function from secret-password (not exactly this one, but other functions from this secret-password are used by evolution-data-server)
- it replaces the current gnome-keyring-daemon and prints it - the PID from 1) will change
- it runs the command from 2) again, which should just work, but it fails with an error "The name is not activatable" instead
- it checks what gnome-keyring-daemon process is running, which should be the same PID as the one at 3).
Having there properly working replace on connection lost, the command at 4) will return the same result as 2) (and will finish without an error), but it's not the case here.
I added some debug prints around and found out that using secret-password API doesn't work the same as using secret-service API first. That is, the secret-service API adds listeners on D-Bus for the given name, but these are not used with the secret-password API usage. It's because service-backend creates the service through GInitable, not through the secret-service API. This patch fixes it.
Unfortunately, it's not enough. The gnome-keyring-deamon replacement does trigger the NameLost D-Bus signal (I see it in dbus-monitor output), but it's not delivered into libsecret for some reason. I do not know why.