Created attachment 118590 [details] [review]
When starting from the .desktop file, use D-Bus activation

This ensures that syncevolution is consistently a child of systemd
(if using the systemd user service) or dbus-daemon (otherwise).

---

I'm less sure about this one. It makes sure only one instance gets started, but it does rely on having dbus-send(1) installed.

Another possibility would be something like

if [ -d "$XDG_RUNTIME_DIR" ] && [ -d "$XDG_RUNTIME_DIR/systemd" ]; then
    exec systemctl start syncevo-dbus-server.service
elif command -v dbus-send >/dev/null; then
    exec dbus-send [...]
else
    exec @libexecdir@/syncevo-dbus-server [...]
fi

but maybe that's too much complexity?

(In reply to Simon McVittie from comment #1)
>     exec systemctl start syncevo-dbus-server.service

systemctl --user start ...

Thanks for the patch, will look at it as soon as time permits.

Comment on attachment 118590 [details] [review]
When starting from the .desktop file, use D-Bus activation

Review of attachment 118590 [details] [review]:
-----------------------------------------------------------------

Indeed, a hard dependency on having dbus-send installed is a bit problematic. I'm going to use this instead:

if which dbus-send >/dev/null 2>&1; then
    # Use D-Bus activation to start it, to take advantage of
    # systemd service management.
    dbus-send \
        --session \
        --type=method_call \
        --print-reply \
        --dest=org.freedesktop.DBus \
        /org/freedesktop/DBus \
        org.freedesktop.DBus.StartServiceByName \
        string:org.syncevolution \
        uint32:0
else
    # Fall back to direct invocation.
    exec @libexecdir@/syncevo-dbus-server @SYNCEVO_DBUS_SERVER_ARGS@ 2>/dev/null 1>&1
fi

(In reply to Patrick Ohly from comment #4)
> I'm going to use this instead

Did this happen?

> if which dbus-send >/dev/null 2>&1; then

You might want

    if command -v dbus-send >/dev/null; then

which I believe is guaranteed to work by POSIX.1-2008 (and usually a shell builtin in practice), whereas which(1) is commonly available but not part of any standard that I know of.

(In reply to Simon McVittie from comment #5)
> (In reply to Patrick Ohly from comment #4)
> > I'm going to use this instead
> 
> Did this happen?

Yes, it is part of the 1.5.2 release from November last year. I just had forgotten to close the bug.

> > if which dbus-send >/dev/null 2>&1; then
> 
> You might want
> 
>     if command -v dbus-send >/dev/null; then
> 
> which I believe is guaranteed to work by POSIX.1-2008 (and usually a shell
> builtin in practice), whereas which(1) is commonly available but not part of
> any standard that I know of.

Good to know, but as it is released now I'll probably not bother with changing it.