| Summary: | Amarok ebuild should get an ogg flag and than depend on gst-plugins-ogg | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sebastian Roeder <sebroeder> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aoliveira, fabian, gstreamer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Sebastian Roeder
2005-03-09 13:31:58 UTC
This flag belongs to the gstreamer ebuild, not amaroK's, IMO. According to the comments at the end of the gst-plugins ebuild (e.g. media-libs/gst-plugins/gst-plugins-0.8.8.ebuild), it should be in the amarok ebuild. Should be fixed in the next version. According to that, yes. But then flac, faad and musepack (and maybe others) should also be added. > But then flac, faad and musepack (and maybe others) should also be added.
I guess we can find a reasonable compromise, maybe taking the rhythmbox ebuild as a reference.
Maybe. It will be very hard to make that way keeping it really compatible with gstreamer and xine-lib at the same time. The ogg flag in amarok ebuild wouldn't work for xine, as xine-lib would need to be recompiled after installing the library (no?). So it would be much more confusing for people using xine, as we would have a flag that just doesn't work. As I can see, all xine stuff was commented out in rhythmbox ebuild, and it features only gstreamer now. I don't see this as an option for amaroK, we have to keep the ebuild compatible with as many engines as possible. Hm, I can't find a _reason_ in the gst-plugins ebuild, why the issue is that overcomplicated. Imho all these flags should be part of the gst-plugins ebuild instead forcing multiple depending applications to do it again and again with such ugly side effects. gstreamer herd? Because the choice of plugins is important at application build-time, not at gst-plugins buildtime. It's more logical to decide what formats you want to support when you build amarok, then at (some random) time when you build gst-plugins. If amarok is your only gstreamer powered application there is no need to build any of the gst video plugins and dep on their respective libraries. But because of their totally pluggable nature gst-plugins make bad deps anyway, there is actually no real need to depend on any of them. The applications should gracefully handle the (non-)existance of plugins & it is really up to the user to choose what they want supported trough plugins. In general so far we chose to do something in between USE flagging every possible plugin (which is an awful lot) that could be used & providing basic functionality with USE flags in the apps. So an oggvorbis, flac, mad dep would be reasonable to provide (see rhythmbox). That this gives some perceived discrepancies with how xine is handled is to be attributed to the different nature & goals of those 2 libraries. gstreamer is much more flexible and that is reflected in the way we handle it & in my opinion it is much closer to how Gentoo would handle it once the much needed USE-based deps come into play. However, as I said this creates a problem, it won't be possible for amarok ebuild to handle these use flags properly for both xine and gstreamer, and choosing only one to support properly for amarok (as it was done for rhythmbox) is not a good choice. Making things work this way will break (or at least make things much more difficult for) dep handling of applications that depend on gst-plugins or some other library (ie, optionally require gstreamer). Are there many applications in this position or only amaroK and rhythmbox? totem also has both xine and gstreamer backends. The xine use flag will make totem use xine so the media use flags such as ogg, flac, theora etc. will do nothing if xine use flag is enabled. totem however does not have runtime switching between backends like amarok has. Really it is the beauty of gstreamer that allows plugins to be added and removed without recompiling all the code or recompiling any apps that use gstreamer. My 2 cents, amaroK having a ogg flag would be complete nonsense. gst-plugins should have a ogg flag or amaroK should install the relevant plugins if the gstreamer flag is enabled. Well, I guess we will live with what foser said for now (an oggvorbis, flac, mad dep would be reasonable to provide). We'll see if gstreamer devs change their minds in the future, or if we find a cleaner solution... amarok-1.2.2 is in portage now, please take a look and report if there's something wrong. The problem I have with this solution is if a user using xine finds they can't play MP3's (for instance if their sound card isn't configured correctly), they see that the 'mad' USE flag is off, it seems pretty sensible to re-emerge amaroK with mad flag on. Of course, we know this would accomplish nothing. Another example would be a user of aRTs or akode who has '-mad' will be unable to play mp3's, since those ebuild actually use the mad keyword (unlike xine-lib) would again find amaroK's new 'mad' flag misleading. Clearly, the gstreamer devs do not care much for other engines (and in the majority of gstreamer players, other engines seem to be an option), or users for that manner. Foser's response seemed to be 'gstreamer is much more in the spirit of Gentoo, so screw xine-lib.' How would foser suggest an application handle playing a file there is no support for, other then simply not playing it? Reality is users generally don't care about "choice", they just want their files to play. Basically you are saying gstreamer in Gentoo should be dumbed down to xine's level? This is definitely not the way it should be, it is not GStreamer's fault that xine-lib is not easily split into relevant plugins that can be installed after the core of xine-lib. If someone cannot play ogg vorbis's with amarok using the xine engine, if they add "oggvorbis" to their use flags and do: emerge --newuse -uD amarok They will be able to play ogg vorbis's with amarok using the xine engine once done. The use case where the user's sound card is not working, surely if they cannot play any sound with any app they would not assume its coz mad is not in their use flags. So this use case is completely bogus. Also I hope you understand that GStreamer is not a playback engine, its a full multimedia framework for recording, playback, transcoding, media filters, streaming, and much much more. Um, yes it should be "dumbed down", if that is what you want to call installing relevant plugins without adding inapproriate USE flags to other apps. Just did a qpkg -l gst-plugins, it has all sorts of stuff (not mp3, ogg or flac of course) including libgstmodplug. Which if I'm not mistaken is plugin to play mod files from old computer games. Which is more then fine with me even though I'll never use it, but I don't see why it is by your logic. In fact, its about 4 times larger gst-plugins-mad... I fail to see why having gst-plugins or a new meta-package carry the USE flags instead would be so heinous. engine, framework... meh. The base gst-plugins ebuild builds everything that does not require external dependencies. That is why you see lots of stuff there, things like videomixer, audioconvert, tcpserversink etc. to name a few. gst-inspect-0.8 shows you a list of plugins and descriptions that you have installed. The other gst-plugins-xyz ebuilds each are one plugin and have an external dependency. You said playback engine, not engine...which is why i cleared the confusion. GStreamer is not just for playback. Hi I don't want to waste developer's time, but I've read trough this discussion and I still don't understand why gstreamer plugins use flags aren't in gst-plugins. The reason foser mentioned is that when you build amarok you can decide what formats to support. But when you merge amarok as your only gstreamer application you get gstreamer and gst-plugins too, so you actually can decide which plugins to support. And when you want to get flac support you add 'flac' to your use flags, and emerge -uDN world will reemerge gstreamer and not amarok. So for use flags in gst-plugins: (in the assumption that gstreamer plugins are installed via portage, and not that application install additional plugins) PROs: * you have ONE place where you can decide what gstreamer plugins to install * you don't have 'wasted useflags'. It's not logical if I compile amarok without flac and still can use flac... * you don't have to reemerge EVERY single application that has gstreamer useflags, when you want to install ONE additional gstreamerplugin, that's completely UNNECESSARY * people don't get confused when using xine and useflags doesn't have an impact. (mp3 doesn't work -> recompile amarok with xine and mad -> mp3 still doesn't work) CONS: * you have to understand that you use gstreamer: when you want to have additional capabilities simple recompiling of amarok (p.e.) doesn't work, you have to recompile gstreamer or emerge -uDN world For me the PROS outweigh the CONS. What do you say? |
