Created attachment 399142 [details, diff] smplayer-14.9.0.6690-r3.ebuild.patch The new ebuild of smplayer-14.9.0.6690-r2 doesn't use the "streaming" USE flag properly. The flag requires MPV to be emerged and if not set (as is by default), it totally turns off the built-in Youtube support (via the qmake YOUTUBE_SUPPORT definition), but still leaves the option (in SMPlayer's options) of using MPV for Youtube videos playing... So here is the programming logic for SMPlayer's Youtube support: 1. SMPlayer has a built-in code for Youtube support. This code is responsible for getting the proper URL for the video/audio etc from Youtube and then pipe it to mplayer (or mpv - depending on user's choice) i.e. even without MPV, SMPlayer can stream Youtube by default 2. The built-in Youtube support is turned on by default and it soft-depends on openssl to be able to use https Youtube URLs. So in the ebuild dev-qt/qtcore:4[ssl] (or dev-qt/qtnetwork:5[ssl]) should be compulsory.... 3. SMPlayer offers the user an option to use the MPV's own Youtube support (which in turn depends on youtube-dl application). This option is available no matter if SMPlayer's qmake definition of YOUTUBE_SUPPORT is on or off (i.e. the ebuild's "streaming" USE flag is set or not) Now about SMPlayer's MPV support: 1. It is built-in SMPlayer and always is on, no matter the qmake defines (or the ebuild's state of the "streaming" flag) 2. It is user's choice (in SMPlayer's options dialog) if he will use mplayer or mpv binary 3. As stated in the upstream's sources "Notes_about_mpv.txt" file, the MPV support is still experimental and has some serious problems... So IMHO, MPV should not be the first choice in RDEPEND of the ebuild... So in conclusion the streaming USE flag is totally unnecessary. I am proposing a new fixed ebuild that follows the upstream logic and leaves the choice to the user if he will use mplayer or MPV... Changelog is: 1. "streaming" USE flag removed 2. "ssl" USE flag in dev-qt/qtcore:4 and dev-qt/qtnetwork:5 - is required to be set 3. Run time dependency is set to either mplayer (as a first choice) or to mpv + youtube-dl 4. Removed the ebuild's disabling of Youtube support Thanks...
The point of the streaming useflag was to allow ssl to be optional, which is why we comment it out if disabled. See bug #543498. About mpv support: .6690 was released for this reason, and mpv offers more features than mplayer, so I decided to set it as soft preference.
I won't discuss on the solution about the needed ssl flag in qtcore and qtnetwork, but AT LEAST please consider making mpv optional when using "streaming" flag, because otherwise you are crippling the application and forcing the user to emerge unnecessary application (like mpv, when mplayer would do the same.. even better job in streaming from Youtube). Because as I already mentioned the: if ! use streaming ; then.... ..... part in the now existing ebuild, turns off entire Youtube support in SMPlayer and if one wants to use this support he has to turn "streaming" USE flag which will pull out mpv (and it is hard dependency here!) ... That is not what upstream devs have in mind.... Thanks
+*smplayer-14.9.0.6690-r3 (22 Mar 2015) + + 22 Mar 2015; Ben de Groot <yngwin@gentoo.org> +smplayer-14.9.0.6690-r3.ebuild, + -smplayer-14.9.0.6690-r1.ebuild, -smplayer-14.9.0.6690-r2.ebuild: + Improve dependency ordering and streaming handling (bug #543642). Put mplayer + back into preferred position over mpv, since mpv is used thru deprecated slave + mode, some smplayer options will not work in mpv, and we have a proper libmpv + GUI in baka-mplayer now. Remove old revisions. I think this new revisions solves most of the issues brought up here, while keeping options open for users who wish so.
