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
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
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.
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.