On Fri, 04 Feb 2011 09:38:37 +1000, Chris wrote:
So it seems that Audacious is not as flexible between its own
version releases? What is with that?
Well, let's not question the developers' decision to bump their "Generic
Plugin API Version" and require plugins to be rebuilt.
Unlike XMMS and a couple of other players, Audacious is still being
developed further. Steadily - in some parts. Hence the occasional change
to plugin interface definitions and base library APIs isn't unusal. And
it's no hard problem. There is a circular dependency between the base
Audacious player and its base plugins anyway. Two separate tarballs, both
If a plugin (also in its binary form) requires certain new features at
run-time, there must be ways to express that dependency with either the
plugin failing to load (with unresolvable symbols, for example) or
Audacious refusing to load the plugin due to plugin version mismatch.
Surely that much can't change between releases to make the
Does that matter? Even if it could be avoided for a minor version release,
there still may be a change for the next major release, such as seen in
2.5-alpha1. It's the packagers' job to implement counter-measures with RPM
dependencies. This is the latest spec change: