Version: 0.7.3 (using KDE 3.1.4) Installed from: SuSE Compiler: gcc version 3.3.1 (SuSE Linux) OS: Linux (i686) release 2.4.21-99-athlon Having completely switched to Noatun / Juk now, I tried to uninstall XMMS from my system. So I was very surprised to discover that Kopete has a dependency on it... It's both strange and unwelcome. Strange because I'd expect KDE to have the necessary multimedia features, and unwelcome because XMMS in turn has a lot of dependencies external to KDE. In principle, I have nothing against linking against an external library (KDE does it a lot, and it's normal), but there are limits. Linking against XMMS calls for so many other external libs that it's getting really awkward. Thank you for your attention!
Remove config.cache from kdenetwork if you have it and run configure again. That way it will detect that you have no XMMS anymore and no longer depend on it. XMMS never was a mandatory dependency for Kopete's NowListening plugin. Martijn
I'm aware of that. I'm saying that it shouldn't pick up XMMS by default, even if it's installed (at least as long as KDE-Multimedia is available). Thank you for your attention.
If you have xmms and Noatun installed but only Noatun running it will still display the title played in Noatun. There's nothing wrong with linking against libraries that actually _are_ installed on the system.
Yes, there is - if you want to uninstall that library later. Linking against everything under the sun makes managing the system really hard sometimes. XMMS is external to KDE and KDE has an equivalent for it, so Kopete should link against it only if the distributor / user explicitely wants it. Of course I also filed a wish item to my distribution so that they produce Kopete packages with relevant dependencies.
> XMMS is external to KDE and KDE has an equivalent for it, so Kopete should > link against it only if the distributor / user explicitely wants it. If we'd do that, then users who actually want xmms support would file a bugreport and ask why we don't pick up xmms automatically. I've never seen a configure script where you have to explicitely turn on support for something that works well and can be found easily on the system. Look at apps like xine or mplayer, they pick up esd over here too although I only want support for oss and arts. I just pass it --without-esd and everything's fine. The only thing we could do is add an option to turn off the xmms search (in case that's not there yet).
Applications where you have to explicitely turn on support for something are very common. I'm a packager, I've seen a lot of them over the years. It makes sense if the developer wants to "encourage" people to use something but provide alternatives nonetheless. You're right about Xine and MPlayer, but the problem is different. Xine and MPlayer have no "builtin" way to render sound, they have to rely on external programs like aRts or Esound, no choice. But Kopere has a "builtin" way for the problem we're talking about: it's a KDE application, it can use KDE libraries. There is a choice and the default one should be obvious. KDE applications should "stay inside KDE" as much as possible, if I can say so. But never mind. I don't want to turn such a small issue into a flame war. I think I made my point, both as a user and as a packager, but as a developer you're better suited to take a decision. I thank you for having taken a bit of your time for discussing this. Regards.
Subject: Re: [Kopete-devel] Wish: Getting rid of the XMMS dependency On Sunday 09 November 2003 14:23, Thibaut Cousin wrote: > But Kopere has a "builtin" way for the problem we're talking about: it's a > KDE application, it can use KDE libraries. There is a choice and the > default one should be obvious. KDE applications should "stay inside KDE" as > much as possible, if I can say so. That's a run-time default, not compile-time. I wouldn't object to a --disable-kopete-nowlistening-xmms configure option if someone submits a patch, but at least at compile time Kopete should build with XMMS support built in. I actually really *hate* software that turns runtime stuff into compile time options, forcing me to recompile or, worse, switch from a binary package to a source package. This is the 21st century, compile-time forcing of user-configurable options really isn't of this time anymore. GUIs are invented for that.
I don't see your point. In the end, the hard fact is: Kopete depends on XMMS, period. I can't install Kopete without having XMMS installed, period. That dependency was forced at compile-time, not run-time, because XMMS was detected even if it was useless. I'm speaking as a user, here. Of course I can get the source and change all this myself, but having relevant defaults is important for packagers. It helps them building more efficient packages. Package dependency is becoming a real pain (soon we'll need 1 Go to install Bash, if you see what I mean, just because of badly-made dependency trees) and any effort in making that more manageable is good to take.
Subject: Re: [Kopete-devel] Wish: Getting rid of the XMMS dependency On Sunday 09 November 2003 15:24, Thibaut Cousin wrote: > I don't see your point. In the end, the hard fact is: Kopete > depends on XMMS, period. I can't install Kopete without having XMMS > installed, period. No, you can. You always could. What you want is to install Kopete without XMMS being _used_ even if it is available. And like I said, you can submit a patch for a --disable-kopete-nowlistening-xmms configure option, but anything beyond that is IMO really *wrong*.
Butting in: make the plugins different external libraries. That is, one .so per program. That way packagers can package a kopete-nowlistening-xmms package which depends on XMMS being installed, but kopete itself and kopete-nowlistening wouldn't.
The way I see it, a packager has two choices when packaging kopete: 1) Enable XMMS support, meaning that the Kopete package *will depend* on XMMS, and force it and other icky things to be installed when installing, for instance, a kdenetwork metapackage. This is *wrong*. 2) Disable XMMS support, meaning that it is only available for people building from source. Which, in this day and age, should be becoming the rarity. We need a third option: Dynamically load XMMS support, or, as Thiago suggests, make plugins for nowlistening for it, Noatun and so on. This way, if you build with XMMS support, you can later run without it. I don't see any other way out.
Now Listening is intended to get moved to kdeaddons, when we get our API stabilised. Stefan's MediaControl kicker applet there has the same dependency, so this problem is due to go away. Maybe a better solution would be to make an XMMS-DCOP bridge plugin for XMMS that implements KMediaPlayer and then change Now Listening and MediaControl to use this.
The last messages for that bugreport seem to make a lot of sense to me, so I can only say that I'm happy I opened it. Moving such a problematic dependency to KDE-Addons sounds logical, as you pointed out with the example of the Mediacontrol Kicker applet. Thank you for your attention!
Version 0.12.1 again depends on XMMS, it's annoying: Why I need XMMS in my system? I use Amarok, don't want a dinosaur Gtk app like XMMS installed into it. I've updated to Kubuntu Dapper KDE 3.5.4 and this version requieres XMMS. Before of that I was using a deb 0.12 package without XMMS dependency. My life was better ;)
This is still a packaging issue. The dependence against XMMS is optional Report the problem to Kubuntu packager.