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): How reproducible: Always Steps to Reproduce: Note that gstreamer-plugins requires arts requires qt. Additional info:
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 creep. 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 use KDE)
As per comments above, I am closing this request.