Arch Linux

Isn't the whole purpose of a plugin, though, the fact that it can fail gracefully when dlopen() fails instead of linking it into the main binary.

Adding these as dependencies would mean that anyone who installs xorg-server, audacious and audacious-plugins onto a fresh system has to install an extra 428.78 MB worth of requirements for plugins that they may or may not use. Arch Linux users are expected (in the sense that it's a distro requirement, not a "we think this would be cool and encourage it") to perform the minimally responsible action of actually paying attention to what their package manager told them when they installed the package -- I'm somewhat disappointed that they are reporting bugs to you, instead of just saying "right, I explicitly exercised the freedom that Arch Linux gave me to NOT install this optdepends".

Naively splitting the package to make every single plugin individually selectable would mean the user now has 65 possible packages to choose from, which isn't exactly a very pretty situation either. Which arbitrary way to subdivide the plugins should we use, then?

...

I'm curious, what is the downside of this other than "ERROR plugin-load.cc:72 [plugin_load]: ... cannot open shared object file: No such file or directory" -- could this error message simply be caught as "WARNING: plugin Transport/neon failed to load because of missing dependencies."

For example, vim has dlopen() support for script interpreters, so if you try to use its tcl support, you might get:

E370: Could not load library libtcl8.6.so
E571: Sorry, this command is disabled: the Tcl library could not be loaded.

Weechat distributes plugins similar to audacious, e.g. /usr/lib/weechat/plugins/tcl.so, it too reports:

Error: unable to load plugin "/usr/lib/weechat/plugins/tcl.so": libtcl8.6.so: cannot open shared object file: No such file or directory
If you're trying to load a script and not a C plugin, try command to load scripts (/perl, /python, ...)

But I've never seen anyone complain about that.

So, I get that Arch Linux users are supposed to know about optdepends and their consequences. And I'm not going to absolutely insist on the packaging being changed, just suggest it.

The technical downside of having plugins installed, but not their dependent libraries, is that Audacious can't even query them for basic info like the plugin name, and will attempt to load them at each startup in order to do so. Whereas plugins that can be successfully loaded, only need to be loaded once to get the info and then don't affect startup time/resource usage thereafter unless actually needed. I take full blame for that design, and it was done before I was aware that Arch Linux existed, and I don't have the spare time to redesign it now.

If you do end up splitting the -plugins package, I would suggest 5 categories:

1. -standard: aac albumart alarm alsa aosd asx asx3 audpl blur_scope cairo-spectrum cdaudio cd-menu-items compressor crossfade crystalizer cue delete-files echo_plugin filewriter flac gio glspectrum gtkui hotkey ladspa m3u metronom mixer mpg123 mpris2 notify playlist-manager pls resample search-tool silence-removal skins sndfile songchange speedpitch statusicon stereo_plugin tonegen voice_removal vorbis wavpack xspf

(deps: alsa-lib lame libvorbis flac mpg123 faad2 libcdio-paranoia libsamplerate libnotify libcue wavpack)

I checked and none of the deps for -standard are over 2 MB.

2. -ffmpeg: ffaudio

(deps: ffmpeg)

Separate only because it's so large.

3. -net: lyricwiki mms neon scrobbler2

(deps: curl libmtp neon libmms)

Only needed if you use network/streaming features.

4. -extra: amidiplug bs2b jack lirc pulse sdlout soxr

(deps: pulseaudio jack2 fluidsynth)

Most users won't need these. You could make -pulse a separate package if you wanted, but the ALSA plugin in -standard also works fine with PulseAudio.

5. -chiptunes: adplug console modplug openmpt sid vtx xsf

(deps: libmodplug libsidplayfp)

For game/chiptune emulation.

Also, these deps are obsolete and can be removed:
libguess libsm dbus-glib gnome-icon-theme hicolor-icon-theme

Thank you for the insight! (Especially the fact that plugins need to be successfully loaded in order for audacious to know what they do.) I don't know that we will actually end up doing so, but I suppose there is no harm in asking the maintainer what his thoughts on the topic are.

Indeed, ffmpeg is the largest dependency chain here, and the proposed -standard grouping only depends on 11.60 MiB of dependencies which seems entirely more tolerable. So, there is that.

i apologize for opening this can of worms.

one could, either as a wrapper around the audacious binary, or as a "post install hook" (if i understand how these are used), scan the possible plugins (stashed off to the side), and choose the ones that might actually load, moving them into their "canonical" locations (and moving out ones that "now fail"). something like this might give an idea:
----
for i in $(find /usr/lib/audacious/ -type f -name "*.so*"); do for j in $(ldd $i | sed 's/ /_/g' | grep 'not_found'); do echo "$i: " $j; done; done
----
which would list plugins that should *not* be in the canonical location. (well, one would change "/usr/lib/audacious" to something like "/usr/lib/audacious/stash.)