libnotify has, to my knowledge, again wrong dependencies. It unconditionally ships with notifiaction-daemon which depends on some gnome stuff. This can't be right. Reproducible: Always Steps to Reproduce:
I'm not sure I understand the issue -- libnotify ebuild does not require notification-daemon unconditionally, but rather allows use of non-gnome alternatives such as knotify or xfce4-notifyd: PDEPEND="|| ( x11-misc/notification-daemon xfce-extra/xfce4-notifyd >=x11-wm/awesome-3.4.4 kde-base/knotify ) Could you explain what I'm missing?
Maybe it's me who is missing something. I understand dependencies as unconditionally needed build- or runtime dependencies. To my understanding, making a library *depend* upon an application which uses it is not correct. It's true that libnotify makes only sense to have, if you own an application which employs it. However... 1) It's not said that aforementioned applications are the only ones that could be used with libnotify 2) It should not be the responsibility of the package manager to *impose* a choice of applications or even to draw a conclusion such as whether it would not be useful to have a certain program without another Portage is meant for flexibility (as is, I assume, any other package manager). Anticipating a user's wishes (possibly wrongly) is unasked for. If you disagree, I will consult the mailing list on this general topic to see how that overall attitude towards portage is. The above should be - and if it's not should be made - a definite policy of portage.
Ok, so the question is not really why libnotify ebuild requires a gnome dependency (which it doesn't) but why it requires any notifier application to be installed. Take a look at bug 253334 for a discussion of the dependency on a notifier app: the reason turned out to be making sure USE=libnotify works as expected without having to repeat this list of notifier alternatives in every ebuild with that useflag. Do you have a cleaner alternative to propose, taking USE=libnotify into account? If so, we can go ahead and reassign this bug to libnotify maintainers...
libnotify is the library and meta- package at the same time. and it's not useful without notification daemon behind dbus call. any new daemons that provide this dbus service, will be added to the list like others have been so far.
