FS#63813 - [audacious-plugins] Please make linked libraries into required dependencies

Attached to Project: Arch Linux
Opened by John Lindgren (jlindgren) - Wednesday, 18 September 2019, 00:32 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 29 May 2020, 02:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

For a while now, Arch Linux has been building Audacious with most plugins enabled, but then listing various libraries required by those plugins as only optional dependencies. Audacious isn't really meant to handle that scenario, and it leads to somewhat arcane dlopen() errors every time Audacious is run.

Please fix the packaging so that all linked libraries are listed as required dependencies. If disk space is a concern, you could split the package into a "minimal" or "standard" set of plugins and a "full" set of plugins.

Additional info:

* package version(s)
any recent version

* config and/or log files etc.
example log line:
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

* link to upstream bug report, if any
https://redmine.audacious-media-player.org/issues/902 (this is a packaging issue though)

Steps to reproduce:

1. Install audacious without some optional dependency (for example, neon).
2. Run audacious.
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Friday, 29 May 2020, 02:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Turned into hard dependencies in audacious-plugins 4.0.3-2.
Comment by Eli Schwartz (eschwartz) - Wednesday, 18 September 2019, 01:26 GMT
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.
Comment by John Lindgren (jlindgren) - Wednesday, 18 September 2019, 02:14 GMT
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
Comment by Eli Schwartz (eschwartz) - Wednesday, 18 September 2019, 02:53 GMT
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.
Comment by Greg Minshall (minshall) - Friday, 20 September 2019, 18:34 GMT
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.)

Loading...