There are many packages whose Use flags affects which gstreamer plugins get installed. A few I can think of are: media-sound/amarok media-video/totem gnome-base/nautilus media-sound/sound-juicer ... Since when one package installs a specific Gstreamer plugin *every* other package can use it, it doesn't make any sense if I'd totem without flac-Useflag and nautilus with flac-Useflag. Wouldn't it be better if gstreamer itself provided this useflags and not every package? Or a gstreamer-plugins metapackage which does that? Reproducible: Always Steps to Reproduce:
> Wouldn't it be better if gstreamer itself provided this useflags and not every package? Or a gstreamer-plugins metapackage which does that? Absolutely. Just the gstreamer herd doesn't agree...
everybody knowledgable disagrees. this was discussed before, just search for the bug.
I did search Bugzilla, but didn't found a bug covering this. Do you have the No.?
> everybody knowledgable disagrees. foser, you're just plain wrong in this case. The plugins are not bound to the applications which can use them, but to gstreamer. This means when two applications optional depend on e.g. the flac plugin and you enable the use flag for the one, but disable it for the other application, both will use the flac plugin nevertheless you disbled the use flag for the one application. The current way to push the dependencies into the applications which use gstreamer is simply braindead.
So is this fixed? I don't think that the current solution makes any sense...
I closed this because this is a dupe, not because you aren't entitled to your opinion. And no, I'm not inclined to do the searching for you today.
I searched Bugzilla for an hour now and didn't find anything. You say it's a duplicate and don't provide the Bug Nr, but mark it CLOSED. But from what Carsten Lohrke above says there are apparently people who don't think that this bug's closed. I don't think it's closed either, cause I can't find the other bug covering this. So *please* give me at least hints where I have to look for that.
You got opinions and decisions, there are always issues where people will not come to an agreement, that is no reason to keep discussing it forever if nothing in the situation has changed. Carlo and the KDE team in general seem to hold another view than the gnome and gstreamer team in this matter, so be it. I have a few gripes with how KDE handles things in some of their respective areas as well, I just don't try to rekindle pointless discussion about them every opportunity I get. Bug #84663 discusses the choices made in detail.
Thanks for you answer. I certainly don't want to waste your time, but I've added a comment to the other bug.
I post it here too: 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?
Wow... nice comments there foser :P Sounds more like use deps are the issue here, even if people ever agreed on an appropriate design...
I don't think use deps are a central point in the proposed design, apps like amarok would just depend on gstreamer and gst-plugins with no additional flags. And for what is worth, my opinion is that the PROs do outweight the CONs here.
Note the 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 If amarok requires gstreamer configured a certain way, that's a use dep- iow merging amarok requires gstreamer to be rebuilt (if needed) with the use configuration it requires. So... either you strictly force gstreamer to carry all the use flags (not representing say amarok's flac conditional), or you enforce that gstream has flac flipped on, which pulls in the dep via that package. Dropping conditionals from (say) amarok and strictly forcing them on gstreamer doesn't strike me as correct for the con stated; to do it proper requires pushing the conditional down to gstreamer, which isn't possible yet. /me shrugs, eenie meenie 'spose.
> If amarok requires gstreamer configured a certain way, that's a use dep- iow > merging amarok requires gstreamer to be rebuilt (if needed) with the use > configuration it requires. Why should this happen? I'm sure there are other packages in portage which change their behaviour when use flags in one of their dependencies are set.
(In reply to comment #13) > Dropping conditionals from (say) amarok and strictly forcing them on gstreamer > doesn't strike me as correct for the con stated; The point is that as soon as a plugin is available to one application it's available to all - despite of having the corresponding use flagged dependency set or not. That's a) illogical and b) when users uninstall a plugin they did not depend on for one application, but are used to it in between because it was invoked by another ebuild, you run into exactly the same problem (and possible "bug" reports): Users who don't know how their applications with gstreamer work. (In reply to comment #14) > I'm sure there are other packages in portage which change their behaviour when > use flags in one of their dependencies are set. Just because you did not noticed more problems with second level dependencies, plugins and the like, doesn't mean they do not exist.
Personally I'd much rather have users confused about a correct control system than them confused about an incorrect one. In any case, applications that depend on xine-lib as a back-end can play whatever xine-lib supports. xine-lib has many USE-flags that control what it supports, which affects everything using it. mplayer-based apps (though fewer afaik) operate the same way. Making gstreamer behave the same way only seems to make sense and promote consistency.
So can someone of the gstreamer herd say something to this. Again: I see no reason why gstreamer should be treated differently from xine-lib. It's unlogical, confusing and it annoys users. Just a simple "OK, we will implement the changes" or a "No, your suggestions suck because of X, Y, Z". (all reasons given above have been confuted). greetings fabian
Just another idea: Create a gst-plugins meta-package with use flags for all packages. Another incosistency: If the use flags stay in the applications ebuilds every ebuild has to accept every gst- useflag (vorbis, aac, dts, ogg, ...)... This is not the case at the moment.
endless nameless
