I just modified the gstreamer.spec to remove a cyclic dependency. gstreamer-plugins-good would depend on gstreamer-devel (for obvious reasons). But gstreamer would depend on gstreamer-plugins-good and gstreamer-plugins-base as those last 2 packages would be obsoleting plugins that used to be in gstreamer itself. That cyclic dependency meant gstreamer-plugins-good would depend on itself during build, thus making library upgrades gstreamer-plugins-good would depend on impossible (as was the case with the recent flac update). Having gstreamer-plugins-good and gstreamer-plugins-base in the comps would solve that problem.
I'm not quite sure I follow here. Nothing else in our stack requires plugins-good? plugins-good has a requirement on -plugins-base, so there shouldn't be a reason to list that one.
(In reply to comment #1) > I'm not quite sure I follow here. Nothing else in our stack requires > plugins-good? As they're plugins, they're not necessary per se, so no applications would have pulled gstreamer-plugins-good themselves. In fact, they wouldn't have needed to because of the dependency conundrum above which would have pulled gstreamer-plugins-good and gstreamer-plugins-base when gstreamer was installed. > plugins-good has a requirement on -plugins-base, so there > shouldn't be a reason to list that one. Nod. Occurences of "gstreamer" in the comps should be replaced by gstreamer-plugins-good, so a decent default set of plugins is installed, and will pull -base and gstreamer. If that's not practical/possible, then all playback apps would need to pull gstreamer-plugins-good themselves as a Requires.
gstreamer-plugins-good added to comps as a default under Sound & Video.