[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#431482: Considerations for 'xmms' removal from Debian

Hi Steve,

I really hate circular depency and I'm not sure it's the better way. In fact, audacious is broken in testing for ages and forcing a build of mcs on mipsel would fix all that crap...

Adeodato Simó a écrit :
* Russ Allbery [Mon, 02 Jul 2007 14:39:20 -0700]:

Steve Langasek <vorlon@debian.org> writes:

Um.  Which version of audacious was this?  libaudacious5 isn't in
testing at all, and the stable (=testing) version of audacious works
fine for me with libaudacious4 which it depends on.

(Also filing this as a bug report.)

windlord:~> audacious
Failed to load plugin (/usr/lib/audacious/Input/libaac.so): /usr/lib/audacious/Input/libaac.so: undefined symbol: vfs_buffered_file_new_from_uri

Files in audacious-plugins are dlopened by audacious, so they don't
depend on any libaudaciousX package. What has happened here is that
there are no package relationships in place to prevent upstream version
skew from happening between the application and the plugins. And
audacious-plugins 1.3.X made it into testing while audacious 1.3.X did

Adam, to fix this, the probably saniest way is to make the plugin
packages depend on audacious with a relationship like this:

  Package: audacious-plugins-whatever
  Version: 1.X.Y
  Depends: audacious (>> 1.X), audacious (<< 1.(X+1)~)

This introduces a circular dependency between audacious and
audacious-plugins, but I think that's okay and preferable to making the
plugins Conflict: audacious (<< 1.X), audacious (>> 1.(X+1)~). I'm sure
others in -devel will agree.

NB: this can't be fixed by just updating the audacious-plugins
dependency in the audacious package, because there are several plugin
packages and audacious does not depend on them all.


Reply to: