OK, I've been meaning to file this bug for over a year, according to an old dev list mail I posted, but am only /now/ getting around to it. KMplayer no longer need depend on mplayer. That's now an optional dependency, with xine and (it appears) gstreamer as other options. Optional dependencies are what USE flags are supposed to be for! <g> xine and gstreamer are currently kmplayer USE flags. mplayer is already a local USE flag for a number of other packages, according to use.local.desc, and I've been successfully running with mplayer in my package.provided, and before that, with it injected, since I discovered the xine support (since xinelib seems to "just work" on the same videos I never could get working, probably due to missing codecs, with mplayer), thru several versions of kmplayer, so mplayer is certainly not a required dependency any longer, if it ever was. Suggested solution: Make kmplayer honor the mplayer USE flag as well as the xine and gstreamer USE flags. If all three are off, certainly default to mplayer support, but make it an option, if xine (and/or presumably gstreamer, I don't know enough about it to be sure it works the same way) is/are on. Reproducible: Always Steps to Reproduce: kmplayer builds, installs, and runs just fine, with xine, without mplayer anywhere on the system except in package.provided. Actual Results: mplayer is an ebuild non-optional depend of kmplayer, forcing me to put mplayer in package.provided in ordered to merge kmplayer without it. Expected Results: kmplayer should have an mplayer USE flag, parallel to the xine and gstreamer USE flags, since mplayer is optional if xine is merged (and presumably with gstreamer as well). I don't see that emerge info is relevant (ask if I'm wrong and I'll attach it), save for the following: ~amd64, so I'm running the latest ~amd64 kmplayer available (0.9.0b as of this writing). It and several previous versions have merged and run just fine without mplayer on the system, using xine.
I bumped kmplayer to 0.9.0c today and added the local USE flag to that version. Please test it and report any problems. Works just fine here after removing mplayer. Thanks for the bug report.
> It and several previous versions have merged and run just fine without mplayer on the system, using xine. This does not suffice. When mplayer is installed, right now mplayer would be a dependency despite USE=-mplayer given. We need determinist behaviour. Please ask upstream for a configure flag, instead having this reliance on autodetection. Marcus: I hope you care about the above a little better, otherwise we'll never see proper reverse dependency support in Portage. Also you did not took care of the case someone chooses to USE="-mplayer -xine".
Reverted the flag for now.
Carsten reading the docs upstream kmplayer does not compile support in for mplayer - it states that mplayer can be installed at a later time and used without the need for recompilation. I tested that assertion and looked at the configure script which seemed to confirm this to me. Please check for yourself - as far as I can tell mplayer is only ever a runtime dependency, please read the section on player backends on the upstream site, http://www.xs4all.nl/~jjvrieze/kmplayer.html You are correct that I overlooked the case where someone chooses -xine -mplayer, and that should result in an error - sorry about that.
Oh, true - I took the mplayer dependency as given all the time, but it should be a RDEPEND of course.
And for this optional runtime dependency a warning should be enough, imho.
