Edit Info Other


/!\ This is a draft

/!\ This is a draft

/!\ This is a draft


This page lists the general goals of RPM Fusion as well as specific work areas the members of the project are planing to or work on or already work on to reach the general goals.


Become the de-facto "official" Fedora add-on repository for all legally distributable free and non-free software the Fedora project doesn't want to ship. That software should be packaged in the same packaging format that Fedora uses and should not require deeper knowledge to install and use. In other words, make FAQs and howtos obsolete as much as possible by making things "just work". Avoid to do things where we would compete with Fedora, and while building and maintaining the repositories try to match Fedora when it comes to rules, guidelines, procedures and infrastructure as much as possible.

More detailed overall goals

The paragraph above outlines the overall general goals (call it "meta goals" if you like) quite well, but (intentionally) doesn't go into the details. The following points are a few examples that in a more verbose way try to outline the RPM Fusion's general goals:

Note that RPM Fusion as well as its contributors have to obey laws in their area of operation and hence can't do everything they would like to do, so trade-offs had to and have to be made. That was (and is) hard, but necessary -- otherwise RPM Fusion maybe wouldn't have lift of at all and definitely would have a smaller contributor base.

One of those trade-offs is: we don't ship software that is not re-distributable and we avoid one well known open-source package used for playing DVDs as that is known to be more problematic than other software we ship. RPM Fusion hopes that sooner or later a different repository (that works on top of RPM Fusion just like RPM Fusion builds on top of Fedora and RHEL/CentOS + EPEL) is built in a part of the world where hosting such a repo isn't a problem.

Specific work items

The members of the RPM Fusion project are well aware that RPM Fusion in a lot of areas doesn't reach the goals outlined above. So there are several things that are done or under discussion, as well as lots of ideas to get closer to a point where we reach the goals.

Ongoing work

automatic dependency checking script

Xavier is working on that

Ongoing work that could need help

improvements for graphics drivers

The RPM Fusion-packaged graphic drivers from AMD and Nvidia are well known and respected among some users. But there is still a lot of room for improvements:

EL repo

We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of "release manager" (ThorstenLeemhuis is doing that job a bit for the Fedora repos; someone else, that actually uses EL more than he does should do it for EL)?

new repos

There are multiple ideas that are slowly discussed:

This is being discussed slowly but there has been no conclusion on the issue yet, nor any work being done to realize it. Once that is solved it might make sense to go out and actively try to get more 3rd party repos merge into RPM Fusion

switch to koji, bodhi, packagedb

Xavier iirc is thinking about that and doing some preparation for that already; would be nice to switch, but no need to hurry, current setup works

Ideas nobody is working on

[musuruan: is it feasible to have some of these ideas as GSoC?]


A small helper app that enables RPM Fusion (and other repos?) and does the initial configuration (e.g. install xine-lib-extras-nonfree if xine-lib was found to be installed earlier).

Detailed description: Users could download that helper app rpm instead of the two release-rpms they have to download not (or the helper app could be part of the rpmfusion-free-release rpm). That helper app then could ask a few questions like "Do you want 'nonfree' packages?" or "do you want to enable compatible repos like the adobe repo?". After that it could act according to what the user wants and what's found on the system (e.g. install rpmfusion-nonfree-release; install xine-lib-extras-freeworld if xine-lib is found; same for gstreamer-plugins, k3b and others; import keys for the repos). Maybe that installer should remain active on the system and tell the users that he might want to install xine-lib-extras-freeworld when he installs xine-lib; but maybe that better done by a yum plug-in or a combination of those two. But users should not have to manually "re-scan" the system.

Maybe this helper app could even enable livna, but that might be tricky as the livna repofile must not be in that package (retrieving the data from the net OHOH should be safe). The app should have a command line interface to be scriptable. And in the default usage the GUI should not ask too many question that might confuse people that are new to linux -- it should "just work" ;-)

Yes, apps that do parts of this exist already (like Autonine/Autoten). But some do stupid things and all ask way to many questions. And everyone could benefit from a sane official install that is provided by RPM Fusion

Jockey for Fedora

Another small app (either tied into or separate from the install helper?) could do things similar to the one jockey does in ubuntu (see https://launchpad.net/jockey and http://people.ubuntu.com/~pitti/screenshots/jockey/ ). Firewing1 is thinking about doing something like this already (which likely will mean: port Jockey to Fedora), which should make the "users don't know which graphics driver to choose" part easier. But the goal should remain: make things "just work", so no configuration options if they are not strictly needed.

mirror lag / skip broken by default

RPM Fusion packages with hard deps on Fedora packages (kmods, xine, qmmp, audacious, ...) often create lots of problems for Fedora users due to mirrors lags (RPM Fusion mirror might have a newer xine-lib-extras-nonfree while the Fedora mirror yum doesn't have the matching xine-lib yet or vice versa; details: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html ) we really need a solution for this


There is a plugin for yum that should improve handling of kmods; that plugin needs adjustments for the current kmod scheme to automatically install the PAE kmod if a PAE kernel is installed (and perhaps to deal with akmod-generated kmod packages in a better way)

form a real steering committee and meet regularly

Activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do "business as usual", which might be very dangerous in the long term. Would a steering committee help? Or how can we make people feel comfortable to "just do things" to improve RPM Fusion without being on a steering committee?

improve reliability of RPM Fusion

We have lot's of "Single Points of Failure" within the RPM Fusion project -- hardware without backup systems or plans how to keep things running in case of a problem; only one person has access to things like DNS, buildservers, or signing keys

improve the docs

There are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the unofficial official 3rd party repo for Fedora, but also be the official 3rd party source for all the docs that can't go straight to Fedora?

[musuruan: can we have a synergy with 3rd party doc sites? Fedora FAQ and Fedorasolved comes to my mind.]

automatically rebuild all kmods

ThrostenLeemhuis has a plan how to do that; it's not that hard, he just needs to sit down and do it


[musuruan: what is the problem in having one?]

[musuruan: I can configure a planet if someone else provides an host, but I can't see the difference from planet.fedoraproject.org, after all we are Fedora contributors too.]

[sunset06: can we build a ~non-intrusive~ instal dvd that uses all the normal fedora stuff, but maybe via a kickstart file adds the RPM Fusion repo defs, and as many useful rpm packages that still fit within one DVD, and default installs a few choice packages ?]

[musuruan: can we look for more contributors in the fedora-docs-list?]

Goals (last edited 2009-02-27 13:04:34 by sunset06)