Bug#431482: Considerations for 'xmms' removal from Debian
* Adam Cécile (Le_Vert) [Tue, 03 Jul 2007 21:57:26 +0200]: Do you mean having the right audacious-plugins dependency on audacious wouldn't be enough ? No, it would be enough. Just to be clear, I'm talking here about the dependency scheme proposed in my first message to this bug report, for *all* packages providing plugins; that is: audacious-plugins, audacious-plugins-extra, audacious-plugins-ugly, and audacious-crossfade. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When it is not necessary to make a decision, it is necessary not to make a decision.
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 [EMAIL PROTECTED] 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 not. 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. HTH,
Bug#431482: Considerations for 'xmms' removal from Debian
Le mardi 03 juillet 2007 à 00:40 +0200, Adeodato Simó a écrit : 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. And the sane way to fix it is to make the plugins link to the library. This way audacious-plugins will depend on libaudacious5 and testing won't be broken again. You should also enforce dependencies between audacious and audacious-plugins in a stronger way. There is no need for a circular dependency, you can just make audacious depend on audacious-plugins (= X.Y), audacious-plugins ( X.Y+1). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Bug#431482: Considerations for 'xmms' removal from Debian
* Adam Cécile (Le_Vert) [Tue, 03 Jul 2007 08:46:45 +0200]: Hi Steve, (My name is not Steve.) I really hate circular depency and I'm not sure it's the better way. Well, do as Joss said and tighten the audacious-plugins dependency in audacious, *and* introduce tight dependencies against audacious in all the rest of plugin packages. No circular dependencies. In fact, audacious is broken in testing for ages and forcing a build of mcs on mipsel would fix all that crap... Well, sorry but no. It is not broken in testing because of mcs not being built, it is broken in testing because it's not packaged correctly. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but That's funny... -- Isaac Asimov
Bug#431482: Considerations for 'xmms' removal from Debian
* Josselin Mouette [Tue, 03 Jul 2007 09:34:19 +0200]: And the sane way to fix it is to make the plugins link to the library. This way audacious-plugins will depend on libaudacious5 and testing won't be broken again. Yah, and what happens when the application (linked against libaudacious4) dlopens the plugins (linked against libaudacious5). -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org It is impossible to make anything foolproof because fools are so ingenious.
Bug#431482: Considerations for 'xmms' removal from Debian
Adeodato Simó a écrit : * Adam Cécile (Le_Vert) [Tue, 03 Jul 2007 08:46:45 +0200]: Hi Steve, (My name is not Steve.) Wasn't talking to new or mistake. I really hate circular depency and I'm not sure it's the better way. Well, do as Joss said and tighten the audacious-plugins dependency in audacious, *and* introduce tight dependencies against audacious in all the rest of plugin packages. No circular dependencies. In fact, audacious is broken in testing for ages and forcing a build of mcs on mipsel would fix all that crap... Well, sorry but no. It is not broken in testing because of mcs not being built, it is broken in testing because it's not packaged correctly. Maybe, I didn't know how to deal with this circular dependency. Here is what I understand, let me know if there's something wrong: audacious 1.3.X should depends on audacious-plugins (= 1.3) and audacious-plugins ( 1.4). That make senses now upstream and me are sure X.Y ABI will always be incompatible with X.Z ABI. If it's fine I'll prepare a new upload for it, however I still can't do anything until mcs is built on mipsel ;) Cheers,
Bug#431482: Considerations for 'xmms' removal from Debian
* Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]: But at a minimum, yes, the audacious-plugins package should be depending on libaudacious by way of shlibdeps. There is no NEEDED entry in the plugins against libaudaciousX. Do you mean hardcoding the dependency instead? (Which, true, solves the situation.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Acaba de... Acaba de una vez... Acaba de una vez conmigo -- Astrud, Masaje
Bug#431482: Considerations for 'xmms' removal from Debian
Do you mean having the right audacious-plugins dependency on audacious wouldn't be enough ? Adeodato Simó a écrit : * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]: But at a minimum, yes, the audacious-plugins package should be depending on libaudacious by way of shlibdeps. There is no NEEDED entry in the plugins against libaudaciousX. Do you mean hardcoding the dependency instead? (Which, true, solves the situation.) Cheers,
Bug#431482: Considerations for 'xmms' removal from Debian
On Tue, Jul 03, 2007 at 09:31:13PM +0200, Adeodato Simó wrote: * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]: But at a minimum, yes, the audacious-plugins package should be depending on libaudacious by way of shlibdeps. There is no NEEDED entry in the plugins against libaudaciousX. That's a bug in the plugins, isn't it? Don't they refer to symbols from libaudacious? Do you mean hardcoding the dependency instead? (Which, true, solves the situation.) Nope. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#431482: Considerations for 'xmms' removal from Debian
* Steve Langasek [Tue, 03 Jul 2007 13:02:50 -0700]: On Tue, Jul 03, 2007 at 09:31:13PM +0200, Adeodato Simó wrote: * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]: But at a minimum, yes, the audacious-plugins package should be depending on libaudacious by way of shlibdeps. There is no NEEDED entry in the plugins against libaudaciousX. That's a bug in the plugins, isn't it? Don't they refer to symbols from libaudacious? Well, point. But the package level strict dependency is still needed because you don't want audacious against lib4 and -plugins against lib5 installed at the same time. Given that, I can understand why plugins would not DT_NEED the main library. (Is that a serious bug? I don't think so, after all they're not directly under /usr/lib.) (Which, true, solves the situation.) This referred to the independent migration to testing situation. Breakage may still occur due to partial upgrades. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Truth is the most valuable thing we have, so let's economize it. -- Mark Twain
Bug#431482: Considerations for 'xmms' removal from Debian
* Russ Allbery [Mon, 02 Jul 2007 14:39:20 -0700]: Steve Langasek [EMAIL PROTECTED] 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 not. 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. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org I went to the race track once and bet on a horse that was so good that it took seven others to beat him!
