Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 300986 - media-sound/quodlibet needs to RDEPEND on additional gst plugins
Summary: media-sound/quodlibet needs to RDEPEND on additional gst plugins
Status: VERIFIED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Sound Team
URL: http://packages.gentoo.org/package/me...
Whiteboard:
Keywords:
: 414189 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-14 13:42 UTC by cx405
Modified: 2012-05-03 04:18 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cx405 2010-01-14 13:42:33 UTC
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!
Comment 1 Mart Raudsepp gentoo-dev 2010-04-11 12:49:41 UTC
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.
Comment 2 Mart Raudsepp gentoo-dev 2010-04-11 12:51:54 UTC
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.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2010-10-31 11:39:21 UTC
not a sound@ bug
Comment 4 Mart Raudsepp gentoo-dev 2010-10-31 21:12:09 UTC
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.
Comment 5 Pacho Ramos gentoo-dev 2011-01-27 18:15:55 UTC
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
Comment 6 Gilles Dartiguelongue gentoo-dev 2011-01-27 19:36:57 UTC
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.
Comment 7 cx405 2011-01-27 20:19:47 UTC
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
Comment 8 Pacho Ramos gentoo-dev 2011-01-27 20:26:13 UTC
This needs to be handled in quodlibet then
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2011-01-29 20:44:50 UTC
(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)
Comment 10 cx405 2011-01-29 21:26:08 UTC
>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.
Comment 11 Samuli Suominen (RETIRED) gentoo-dev 2011-01-29 21:30:42 UTC
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.
Comment 12 cx405 2011-01-29 22:13:49 UTC
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
Comment 13 Samuli Suominen (RETIRED) gentoo-dev 2011-01-29 22:22:26 UTC
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.
Comment 14 Samuli Suominen (RETIRED) gentoo-dev 2012-05-03 04:18:17 UTC
*** Bug 414189 has been marked as a duplicate of this bug. ***