Project

General

Profile

Feature #902

enhanced error message when plugin not found

Added by Greg Minshall about 1 month ago. Updated about 1 month ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
September 17, 2019
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

when plugin_load() fails calling g_module_open(), it might be nice to give the user a message such as "Is neon installed on your system? execution will continue but features provided by neon will be unavailable". this may help the user to realize quicker what is going on.

background: on arch linux, i installed both audacious and audacious_plugins. running audacious, i got lots of messages like
----
ERROR plugin-load.cc:72 [plugin_load]: /usr/lib/audacious/Transport/neon.so could not be loaded: libneon.so.27: cannot open shared object file: No such file or directory
----
and it took me an embarrassingly long time to realize that, okay, something called "neon" wasn't installed, and so couldn't be used but, hey, no big deal.

(thanks for the very nice program!)

History

#1 Updated by John Lindgren about 1 month ago

  • Status changed from New to Rejected

This is a packaging issue on the Arch Linux side. I created https://bugs.archlinux.org/task/63813 for you.

#2 Updated by Eli Schwartz about 1 month ago

Greg,

I find myself extremely confused, why did you not read the output of pacman when installing audacious-plugins? It specifically warned you about these optional dependencies?

Also, if at some point you genuinely thought there was an issue with missing libraries, that would almost certainly be a rebuild issue which would need to be directed at the Arch Linux bugtracker, there is nothing Audacious can do about the possibility of we (Arch Linux) having mismatched libraries and needing to rebuild the package.

#3 Updated by Greg Minshall about 1 month ago

hi. thanks to both for your answers. i can't defend my not having paid closer attention to the output when installing the packages. i did wonder where to report the issue (thinking of both glib -- till i realized its error message was perfectly reasonable -- and arch).

it would be nice to have a package management system that could hold some bits of a package (like audacious-plugins) until some "weak" dependency is satisfied (then withdraw the bits if the dependency is removed). but, maybe that's asking too much? however, it would be nice, when the user, after installing audacious and the plugins, installs, e.g., neon, to have its functionality "pop up" the next time audacious is launched.

but, i would argue for the desirability of providing a message, as a poor user (me, say) can use all the help s/he can get to figure out what is going on.

("desirability" is not equal to "it should/can/etc. be done", as the latter imply prioritization, available development cycles. and, i can see how even generating a [more] useful message would not be a simple 2-line fix.)

again, thanks.

Also available in: Atom PDF