Red Hat Bugzilla – Bug 108463
gstreamer-plugins should be split up
Last modified: 2007-11-30 17:10:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux ppc; U;) Gecko/20030130
Description of problem:
I don't want to appear as an irrational GNOME zealot, but it seems wrong that
gstreamer-plugins, a core component of GNOME, requires Qt. The aRts gstreamer
plugin could easily be packaged as a separate RPM, say gstreamer-arts. I
understand that Qt is required by redhat-artwork anyway...but it just doesn't
seem right, man.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Note that gstreamer-plugins requires arts requires qt.
Created attachment 97622 [details]
Patch that separates aRts plugin into its own RPM
This patch modifies the RPM specification for 0.7.3-2 so that it builds a
separate binary RPM for gstreamer's aRts plugin. This removes the aRts/QT
dependency from gstreamer-plugins and adds it to gstreamer-plugins-arts. In
general, more fine-grained packaging of gstreamer plugins may be nice for users
because of the wide range of dependencies within them (see Mandrake's scheme).
After FC2, I would like to split up the plugins in a much more
fine-grained way, similar to how Debian does it.
Just splitting out Qt would be inconsistent.
Ok, I've been convinced that it isn't worth it to split the plugins up
(apparently it was done in the past and went badly).
One major argument against it is that it will break upgrades. So I
guess we're stuck with it.
For the record, the rpms provided upstream from gstreamer.org are little more
fine-grained, but still doesn't split out arts/qt.
Could we use the lessons learned from the recent X11 split up to split up
gstreamer without causing upgrade problems? The gstreamer-plugins package pulls
in a lot of dependencies that may not be really necessary.
Not sure why it needs to brea(In reply to comment #3)
> Ok, I've been convinced that it isn't worth it to split the plugins up
> (apparently it was done in the past and went badly).
> One major argument against it is that it will break upgrades. So I
> guess we're stuck with it.
Not sure why it needs to break upgrades. An upgrade can pull in all the packages
to resolve that as the last case and a fresh installation can install things in
a modular way. While Gstreamer is going to be used in KDE in a future version
installing QT is unnecessary in many instances. We should avoid that dependency
If there are other reasons not to split this up please mention them so that I
can document those rationale properly. Feel free to use the
http://fedoraproject.org/wiki for this.
Can we do this for FC6?
Well, in FC5 the gstreamer-plugins-* packages don't include the
arts plugin and don't require arts or qt, so the main problem in the
bug seems to be resolved.
It seems unlikely that it's going to be split up more than the
upstream gstreamer-plugins-base, -good etc., especially judging
by Colin Waters's comments above. I'm just not sure that users
really want lots of seperate packages for each type of file
support (as opposed to larger things like: install this if you
As per comments above, I am closing this request.