Hello! I have a small improvement for QuodLibet ebuild, to add network-radio support for non-gnome systems (-gnome) or systems with gnome(-like) DEs installed which do not desire presence of gnome-vfs. Quodlibet will not provide net-radio support unless gstreamer http support is installed. QL Wiki recommends to pull gnomevfs for this(which is depricated). http://code.google.com/p/quodlibet/wiki/Guide_Requirements "Internet Radio depends on HTTP support in GStreamer; the most common way to get this is to install the GNOME-VFS modules for GStreamer." However, member __tim over #gstreamer has suggested to install - media-plugins/gst-plugins-soup and - media-plugins/gst-plugins-neon Presence of only this two plugins enables fully functional "Internet Radio" menu entry in QL without gnome-vfs. To sum things up, net-radio support does not need gnome-vfs, but only this two gst-plugins to become fully functional. I would really appreciate someone to update ebuild, to reflect this. :) Thank you very much!
Why was this reassigned without reason from sound@ to gstreamer@? We do not maintain quodlibet. Nor do we primary maintain gst-plugins-meta. quodlibet appears to have its own gst-plugins-* dependencies, so it should revise those itself. And it should stop using gst-plugins-gnomevfs, it's deprecated and I want to get rid of it. Either gst-plugins-soup or gst-plugins-neon should support HTTP transport, perhaps also gst-plugins-gio (through libsoup too); both should not be necessary. I suggest picking gst-plugins-soup and making sure that works.
Had an outdated checkout, seems the latest version uses gst-plugins-meta now. gstreamer@ does not deal with gst-plugins-meta though, just a backup herd or so.
not a sound@ bug
I get to say yet again - gstreamer does not maintain gst-plugins-meta. Reassigning to maintainers. gstreamer@ has no problems with gst-plugins-meta growing a metric ton of USE flags while we'll migrate to something better later on.
I have been checking use.desc and have seen there is no global USE flag for "neon" neither "soup", then, I think that would be better if quodlibet would RDEPEND on needed plugins itself as they doesn't look to be widely needed
Policy for the meta _is_ that it should _not_ be used for _needed_ plugins, only runtime optional like those for music or video players or transcode applications. Totem for example directly depends on gst-plugins-soup because it needs it for youtube player feature.
I've been using Gentoo for around a year now, nonstop. This bug belongs to QuodLibet ebuild. Quodlibet provides internet radio, if media-plugins/gst-plugins-neon (and only it) is installed in the system. It does not need to be rebuilt. Maintainer should either 1) add "radio" USE to quodlibet ebuild with media-plugins/gst-plugins-neon as rdepend. or 2) add a small after install notice that quodlibet provides internet radio if media-plugins/gst-plugins-neon is present in the system I put more respect in first option because this will pin the library and lessen post-install passes. This does not belong to gstream-meta, unless gstream-meta decides to globally provide subdefined package list that provide that internet radio functionality. Best regards
This needs to be handled in quodlibet then
(In reply to comment #8) > This needs to be handled in quodlibet then > nope, won't start listing optional individual plugins in ebuilds. only those that are absolutely necessary (the application eg. crashes without)
>nope, won't start listing optional individual plugins in ebuilds. only those that are absolutely necessary (the application eg. crashes without) Following your logic Gentoo should be binary distro, not metadistribution. Please show me the guideline, which you us to make this statement otherwise it is personal choice and should not be taken into main portage tree. This is clearly quodlibet USE flag - an option to add internet radio functionality into QL only. Please fix or allow other to fix.
The gstreamer maintainers decided to split it into separate packages under media-plugins/ instead of providing USE flags for eg. media-libs/gst-plugins-good. So, yes, you need to emerge those optional gst-plugins you want, by hand. That's a feature gstreamer maintainers have provided you with. Same way I would refuse adding USE="mp3" to quodlibet's ebuild that depends on media-libs/xine-lib[mp3]. It simply doesn't belong there. Now, stop reopening this bug, thanks.
But HOW are unaware users know that if they add unspecified neon, the player will be able to play net radio? This is QL only flag/option. No other gstreamer app is using or connecting dynamically to neon. If it is not the case(more than one player uses the combo for internet datastream), please combine neon and soup as "streaming" group (-streaming- USE) and add it to meta. Please add information in ebuild at least. Although things like this will make gentoo even less intuitive (best one is use flag), regardless of gstreamer-meta - the user will at least be informed of the functionality. Thing that I personally find very good in Debian is "suggests" feature where you immediately see which packages may be worth adding as they extend the functionality. Additionally many gstreamer players are unable to play specific formats, regardless of gst plugins installed, so meta has no function over them. Meta should really have a meaning to "keep(pin) a group of codec packages regardless of installed applications". For example: if we connect to gst plugin, via gst-meta USE, which is, again, pulled by specific sound app USE - we will end-up with too much or too less pulled packages. I will not reopen as you seem to avoid discussion and possible improvement, thanks for reading though(I hope). Regards
I too like "Suggests: " and would like to see such feature in Portage to get uniform behavior for these optional, runtime-only, depends. Even if it only printed out the packages as a message. How about opening a bug for dev-portage@ about this? As an feature request.
*** Bug 414189 has been marked as a duplicate of this bug. ***
