Since many (all) ebuilds depending on gstreamer also include useflags for additional gstreamer codecs it would be useful, IMO, to add a use-expanded variable like GSTREAMER_PLUGINS="" for selecting, once and for all these packages, with codecs should be installed.
Why do we need USE_EXPAND when there are already use flags in place? Just doesn't make sense. What exactly should that do?
(In reply to comment #1) > Why do we need USE_EXPAND when there are already use flags in place? Just > doesn't make sense. What exactly should that do? > let's look at the totem's and muine's ebuilds. in both of them (they can both use xine or gstreamer backends) you can see something _like_ this: !xine ( =media-libs/gstreamer-0.10* =media-libs/gst-plugins-base-0.10* =media-libs/gst-plugins-good-0.10* ... mad? ( =media-plugins/gst-plugins-mad-0.10* ) vorbis? ( =media-plugins/gst-plugins-ogg-0.10* =media-plugins/gst-plugins-vorbis-0.10* ) funkycodecname? ( =media-plugins/gst-plugins-funkycodecname-0.10* ) ) these use flags generally are used only for taking-in specific dependencies, and aren't used during the build of the program. I firstly thought about a use-expanded var because I took as example the work that has been done for modularizing xorg dependencies, but like you said a use-expanded variable isn't needed for reaching the goal of grouping all gst-plugin dependencies in one ebuild, listing them as RDEPENDS of media-libs/gstreamer. This would be simpler to the user (he/she can choose in one place which codecs to build) and to the developer (he/she doesn't have to replicate code among the ebuilds, only depend on media-libs/gstreamer)
Eh, these "convenience" deps pretty much suck and are invalid; besides they can cause nifty circular dependencies. Don't really see why they should spread even further.
Created attachment 114473 [details, diff] gstreamer-0.10.12.ebuild patch Ok, no one from the gstreamer herd commented on this bug... As a proof-of-concept I cooked up a small patch that copies some of the codec dependecy from the totem's ebuild RDEPEND var into the gstreamer's ebuild PDEPEND one, however this creates a problem: gstreamer has to be rebuilt whenever one of those new useflags changes its state even if the recompilation is not really needed (actually all packages having such dependency scheme have to do, so it's still an enhancement), so it may be wiser to use a new meta-ebuild instead of modifying the gstreamer one.
don't forget USE=aac -> gst-plugins-faac and gst-plugins-faad ;) my twopenceworth - i'd much a compile of gstreamer pulled in all the dependencies than have to scratch my head (admittedly not for very long) on why I've emerged gstreamer and haven't got e.g. aac support. (I actually started scratching my head when someone had managed to miss a 'convenience' dependency having never emerged gstreamer directly, so slightly more excusable).
nope, not adding USE flags for optional runtime depends which forces unneeded rebuilding when new flags are enabled
(In reply to comment #6) > nope, not adding USE flags for optional runtime depends which forces unneeded > rebuilding when new flags are enabled > say you have the "mad" use flag turned off, and then you turn it on: all apps using gstreamer and having "mad? (media-plugins/gst-plugins-mad)" in their deps would need to be recompiled when they have not really to. Maybe, instead of having gstreamer depending directly on the plugins, there could be a meta-ebuild doing the work: the recompilation cost of such meta-ebuild would be near zero.
(In reply to comment #6) > nope, not adding USE flags for optional runtime depends which forces unneeded > rebuilding when new flags are enabled > Then how is this supposed to work for general media players (like kaffeine, amarok, totem, etc), that want to play every (in)conceivable format supported by the backend, if they all have to keep track of what codecs the backend/gstreamer supports, and only be able to enable support for known codecs? Doesn't that kinda completely miss the point of a generalized backend, so media players don't have to worry about specific formats? And as Alessandro says, changing the USE flags would then cause Amarok *and* Totem *and* others to recompile so they can pull in new dependencies that they're not directly concerned about, as opposed to *just* gst-plugins-good *or* bad *or* ugly, which are concerned about which plugins are built.
Gnome ppl wanted media-plugins/gst-plugins-meta so we have that now, but it could use more USE flags to be useful.
*** Bug 207516 has been marked as a duplicate of this bug. ***
The general plan is that, as you add new packages depping on gst-plugins-meta, you add the appropriate use flags. I personally see little point in adding use flags to the meta just to have more use flags.
For your info, I added the dvb and mythtv use flags to the -meta in prep for the upcoming totem 2.22 release.
this changes are in gnome overlay.
these is now in tree with gnome 2.22
