Bug#887506: notification-daemon: The notification-daemon binary moved to a different location

[Simon McVittie]

Control: clone 887506 -2
Control: severity -2 important
Control: clone -2 -3
Control: clone -2 -4
Control: reassign -2 python-notify2
Control: retitle -2 python-notify2: Don't rely on location of notification-daemon
Control: reassign -3 libgtk2-notify-perl
Control: retitle -3 libgtk2-notify-perl: Don't rely on location of notification-daemon
Control: reassign -4 golang-github-thecreeper-go-notify
Control: retitle -4 golang-github-thecreeper-go-notify: Don't rely on location of notification-daemon

On Wed, 17 Jan 2018 at 17:47:03 +0200, Adrian Bunk wrote:
> debian/runtests.sh: 5: debian/runtests.sh: /usr/lib/notification-daemon/notification-daemon: not found

The exact location of the notification daemon shouldn't be treated as API:
the entry point is /usr/share/applications/notification-daemon.desktop.
It's ${libexecdir}/notification-daemon, and the default ${libexecdir}
changed between debhelper compat levels (which is what happened here),
and might well change again in future (for example to /usr/libexec when
Debian Policy picks up a newer FHS version).

python-notify2's runtests.sh should launch the desktop file instead,
for example with gtk-launch from libgtk3-bin:

    -/usr/lib/notification-daemon/notification-daemon &
    +gtk-launch notification-daemon.desktop

The same is true for other packages that launch notification-daemon for
their tests.

> This is caused by the following unintentional
> change in notification-daemon 3.20.0-2:
> -/usr/lib/notification-daemon/notification-daemon
> +/usr/lib/x86_64-linux-gnu/notification-daemon

It would be straightforward to change this back by passing
--libexecdir=/usr/lib/notification-daemon to configure, and that's
probably the most expedient short-term answer (which is why I haven't
closed this bug, and why I reduced the severity of its clones).

    smcv