Previous case of a package already in RPM Fusion then submitted to fedora with different options was gstreamer-plugin-bad introduced as gstreamer-plugins-bad-free in fedora while been adapated in RPM Fusion at the same time.

That been said, that's a special case where everything was plugins, not a single application.

So whereas you could submit a mixxx-free package in fedora amputated from it's fully upstream mp3 support via libmad. The RPM Fusion counterpart coudn't extend the fedora package.

Best would be to have mixxx binary to "dlopen" libmad so introducing mixxx within fedora would not lose any upstream feature that users will need in some corner cases.

The second choice for me would be to just maintain mixxx in RPM Fusion instead of fedora as it's a very little disadvantage over having an incomplete package in fedora.

In this case, you just need to request maintainership of the package, please see: http://rpmfusion.org/Contributors/CVSRequests

Nicolas (kwizart)

2014-04-09 5:55 GMT+02:00 Tonet Jallo <tonet666p@gmail.com>:

Let me see if I understood, you say i can package a mixxx without mp3 support for Fedora repo and other package mixxx-freeworld with only mp3 plugins for RPM Fusion, right?

2014-04-01 21:12 GMT-05:00 Kevin Kofler <kevin.kofler@chello.at>:

Tonet Jallo wrote:
> Mmmmm, but this is not the problem, the problem is the version of mixxx
> already in rpmfusion and i need it name will changed to mixxx-freeworld
> same to audacity-freeworld.
> Sorry if you don't understand some parts, my english is not very good.

His point is, if mixxx can support plugins for the patent-encumbered codecs,
then it can MOVE to Fedora and RPM Fusion can ship a mixxx-freeworld plugin
that works with the Fedora mixxx (the preferred way to package support for
additional codecs in RPM Fusion) rather than a package that Conflicts (a
solution that is only used as a last resort).

Kevin Kofler