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

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.

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.

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)