Bug 103919 – media-video/kmplayer needs mplayer USE flag

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Duncan 2005-08-27 06:37:49 UTC]

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.

[Comment 1 Marcus D. Hanwell (RETIRED) 2005-08-29 05:46:07 UTC]

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.  

[Comment 2 Carsten Lohrke (RETIRED) 2005-08-29 07:19:13 UTC]

> 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".

[Comment 3 Carsten Lohrke (RETIRED) 2005-08-29 07:19:33 UTC]

Reverted the flag for now.

[Comment 4 Marcus D. Hanwell (RETIRED) 2005-08-29 08:40:07 UTC]

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. 

[Comment 5 Carsten Lohrke (RETIRED) 2005-08-29 16:02:41 UTC]

Oh, true - I took the mplayer dependency as given all the time, but it should be
a RDEPEND of course.

[Comment 6 Carsten Lohrke (RETIRED) 2005-08-29 16:03:03 UTC]

And for this optional runtime dependency a warning should be enough, imho.