Hi, libnotify is an hard dep for empathy, which can easily disabled by conditionnal compilation in sources, and an enable option in the configure script. This support should be optional because it's not a critical dependency for the proper functioning of the program (like telepathy for example). You'll find in attachment a patch which solves the problem. mrpouet ;) Reproducible: Always
Created attachment 191048 [details, diff] the patch which solves the problem
Upstream bug? Won't be added unless we know upstream's stand on this.
Created attachment 191383 [details, diff] empathy-2.26.1-configure-notify-option.patch
Created attachment 191385 [details, diff] empathy-2.26.1-client-notify-support.patch
upstream opened see http://bugzilla.gnome.org/show_bug.cgi?id=582776, and my patch is now more "atomic", one feature per patch, news patches are attached.
Created attachment 191387 [details] the new ebuild including patches, revision bumped
If upstream isn't doing it, we shouldn't either. We already have hard deps for libnotify and it's a small thing. If you want to globally not have notification messages, you can uninstall notification-daemon that catches the D-Bus messages and actually shows the popups or something. I can sympathize with upstream, as in the current form it makes lots of places have hard to maintain ifdef's (when code changes around those areas - what variable definition needs to go inside the #ifdef block, which not, etc etc). If the patch would be in a way that would factor it so that the #ifdef stuff is located in one place (like the kernel code tries to do for example, does function calls always, but if the support isn't compiled in the function called is empty and hopefully gets optimized out), then it might be more acceptable. However I don't see it necessary to do this, libnotify ain't a bad thing.
