This is a draft

This is a draft

This is a draft

Goals

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.

Overall

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:

• provide software that is free (as defined by the Fedora licensing guidelines) as pre-compiled RPMs for Fedora and RHEL/CentOS + EPEL in a yum repository that seamlessly can be used by the packaging tools from Fedora during and after install; packages in that repo should not automatically replace packages from the distributions the repo is designed for

• provide distributable non-free software (anything that is not "free" according to the Fedora guidelines) in a different repo that is similar styled to the free repository
• rely on the packaging or update guidelines from Fedora for RPM Fusion as much as possible; only enhance/adjust those rules in areas where it is needed for the specific nature of RPM Fusion
• when possible, don't do things in RPM Fusion that could be done in Fedora, as doing it there is better for everyone (albeit sometimes harder to realize)
• try to get more repos to merge into RPM Fusion
• make RPM Fusion package repositories as well as the packages in it as easy to use as possible (e.g. make it "just work") to make sure that computer, Linux, or fedora newbies have an easy time getting those things that Fedora doesn't want to support to work.

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 build in a part of the world where host 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:

• users have to know which driver they need and that confusing people
• the tools from AMD and Nvidia don't work too well; sometimes they remove important parts specific to our driver packages from xorg.conf and thus break 3D
• Fedora uses very recent kernels and so often, the kmod packages won't compile; help from someone with lots of kernel know-how would be very appreciated.

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:

• get kde-readhat integrated into RPM Fusion as a dedicated new repo
• start a experimental repo with updates that are not ready for updates{,testing}
• start a staging repo with unreviewed things (only license check)
• a repo with packages that replace packages from the distribution they were build for)

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?]

Installer

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 save). The app should have a command line interface to be scriptable. And in the default usage the GUI should not ask to 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 of the install helper?) could 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 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

[musuruan: instead of writing something from scratch cannot we use Jockey? It is designed to be distribution agnostic.]

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 be have a newer xine-lib-extrs-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

kmod-plugin

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 on 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

misc

• rpmfusion-buildsys-list is broken;
• no announcement mailing list;

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

• no real planet.rpmfusion.org or other way to get important information out to the users.

[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.]

• Chris Nolan was working on using wordpress to publish news. The integration with FAS has already been done it was working. Project stalled when requesting a valid SSL certificate for the domain. No further updates.
• no RPM Fusion Fedora remix maintained within the project; do we want one? Or even proper install DVDs that already contain packages from RPM Fusion?
• improve docs for contributors and users; document processed

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

• a small script or rpmfusion-packager package with a script that does things like

  alias plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg plague-client'
  alias cvsf='export CVSROOT=:ext:USERNAME@cvs.fedora.redhat.com:/cvs/extras'
  alias cvsrf='export CVSROOT=:ext:USERNAME@cvs.rpmfusion.org:/cvs/free'
  alias cvsrnf='export CVSROOT=:ext:USERNAME@cvs.rpmfusion.org:/cvs/nonfree'

• we need a place where to host RPM Fusion projects. Something like Fedora Hosted.