The missing codec problem
You install a fresh copy of Fedora, fire up your media player, and the video refuses to play. You try to install the NVIDIA driver and the package manager tells you the name does not exist. You are not missing a configuration step. Fedora ships with a strict free software policy. Proprietary codecs, closed-source GPU drivers, and commercial applications live outside the official repositories. You need to add RPM Fusion to bridge that gap.
What RPM Fusion actually does
RPM Fusion is a community-maintained repository that splits packages into two distinct categories. The free repository contains open-source software that Fedora excludes for packaging policy reasons, not licensing reasons. These packages often depend on libraries that Fedora considers out of scope for the base system. The nonfree repository contains proprietary software, closed-source hardware drivers, and packages that link against nonfree components. Adding these repositories does not modify your existing system. It only tells the package manager where to look for additional packages.
The installation process drops configuration files into /etc/yum.repos.d/. Fedora's package manager reads that directory on every transaction. The files define the mirror URLs, enable flags, and GPG key paths. When you run a standard package command, the resolver merges the official Fedora metadata with the RPM Fusion metadata and calculates a dependency graph across all enabled sources.
Run dnf repolist after enabling the repositories to see the full list of active sources. The output confirms whether the new channels are visible to the resolver.
Enabling the repositories
Here is how to enable both repositories in a single transaction. The command pulls the release packages directly from the RPM Fusion mirrors and installs them as configuration sources.
sudo dnf install --allowerasing \
https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
# --allowerasing permits dnf to remove conflicting Fedora packages
# $(rpm -E %fedora) expands to your current release number automatically
# The two URLs fetch the .rpm config packages for free and nonfree repos
You will see a GPG key import prompt during the transaction. Type y and press Enter. The package manager needs the key to verify package signatures before it trusts the new repository. Fedora's security model requires explicit user approval for new signing keys. After the transaction completes, the repository configuration files are in place. Run dnf upgrade --refresh to pull the latest metadata from the newly added sources. The refresh flag forces the package manager to discard cached metadata and download fresh repository headers.
Always run dnf upgrade --refresh after adding a new repository. Stale metadata causes dependency resolution failures that look like broken packages.
Verify the setup
Here is how to confirm the repositories are active and ready for use.
dnf repolist enabled | grep -i rpmfusion
# Lists only enabled repos matching rpmfusion
# You should see rpmfusion-free and rpmfusion-nonfree
If both lines appear, the setup is complete. You can now install packages like nvidia-driver, ffmpeg, or steam directly through dnf. The package manager will resolve dependencies across the official Fedora repos and RPM Fusion automatically. You can also check repository priorities to ensure RPM Fusion does not override base system packages.
dnf repoquery --available --qf "%{name} %{priority}" | grep rpmfusion
# Queries available packages and prints their repo priority
# Fedora base repos default to priority 98
# RPM Fusion defaults to priority 99, meaning lower precedence
The priority system prevents RPM Fusion from replacing core Fedora packages unless explicitly requested. A higher number means lower priority. The resolver prefers the base system packages first.
Check the priority output before installing system-wide libraries. Lower precedence keeps your base system stable.
Common pitfalls and error messages
The --allowerasing flag is the most common point of confusion. Fedora ships with certain packages that provide overlapping functionality. For example, Fedora includes gstreamer1-libav for basic media decoding. RPM Fusion provides ffmpeg and ffmpeg-libs. The package manager sees a file conflict and refuses to proceed unless you explicitly allow it to erase the conflicting package. This is safe. The RPM Fusion packages are built to replace the Fedora equivalents cleanly. If you skip the flag, dnf will abort with the following error:
Error: Transaction test error:
package ffmpeg-libs-7.0.2-1.fc40.x86_64 conflicts with gstreamer1-libav provided by gstreamer1-libav-1.24.2-1.fc40.x86_64
Add the flag and the transaction completes. The resolver will remove the Fedora package and install the RPM Fusion replacement in the same atomic transaction. Your system remains consistent.
Another common issue involves dnf5. Fedora 41 switched the default package manager to dnf5. The command syntax remains identical, but the underlying resolver is faster and handles conflicts differently. If you see a warning about dnf5 compatibility, ignore it. The release packages detect the environment and install the correct configuration files. Always check journalctl -xe if a package installation fails after enabling RPM Fusion. The logs will show whether the failure is a missing dependency, a broken mirror, or a signature mismatch.
Convention aside: repository configuration files in /etc/yum.repos.d/ are user-modified. The base files ship in /usr/lib/yum.repos.d/. Never edit the /usr/lib/ copies. Package updates will overwrite them. Edit /etc/ or use dnf config-manager to adjust priorities or enable specific repos. SELinux denials related to repository metadata are rare, but if you see audit: type=1400 entries in journalctl -t setroubleshoot, run restorecon -Rv /etc/yum.repos.d/ to fix context labels.
Run journalctl -xeu dnf after a failed transaction. Read the actual error before guessing at missing flags.
When to use RPM Fusion versus other sources
Use RPM Fusion free when you need open-source packages that Fedora excludes for packaging policy reasons. Use RPM Fusion nonfree when you require proprietary codecs, closed-source GPU drivers, or commercial software. Use Flatpak when you want sandboxed applications that update independently of the system package manager. Use COPR when you need bleeding-edge packages or developer snapshots that are not ready for a stable repository. Stick to the official Fedora repositories when you are managing a production server or a system that requires strict audit compliance.