Story / scenario opener
You just switched to Fedora and need a specific piece of software. The default repositories do not have it. You find a third-party project that ships a .repo file or a COPR build. You need to add it safely without breaking your package manager or compromising your system.
What's actually happening
DNF reads repository definitions from /etc/yum.repos.d/. Each .repo file tells DNF where to fetch package metadata, how to verify cryptographic signatures, and whether the repository is active. Think of it like adding a new shelf to your library. The shelf holds the books, but you still need the librarian's stamp to trust them. DNF handles the stamping with GPG keys. If the key is missing or the metadata is corrupted, DNF refuses to download anything from that shelf.
The package manager does not trust third-party sources by default. Fedora's core repositories ship with pre-installed keys and verified metadata. External sources require explicit configuration. You are telling DNF to trust a new location, fetch its package index, and compare it against your current system state. A misconfigured repository can block upgrades, trigger dependency conflicts, or silently install unverified packages. Configure it correctly the first time.
The fix or how-to
Method 1: Install a repo RPM
Most established third-party projects ship a small RPM that places the correct .repo file and GPG key in the right directories. RPM Fusion is the most common example. The RPM handles variable substitution and key import automatically.
Here's how to install the RPM Fusion free and non-free repositories in one transaction.
sudo dnf install \
https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
# $(rpm -E %fedora) expands to your current release number automatically
# .noarch.rpm means the package works on any CPU architecture
# dnf resolves dependencies and places the .repo files in /etc/yum.repos.d/
The RPM installs the configuration files and imports the GPG keys into DNF's keyring. You do not need to touch the filesystem manually. DNF will recognize the new repositories on the next metadata refresh.
Reboot is not required. Run dnf upgrade --refresh to pull the new metadata immediately.
Method 2: Enable a COPR repository
COPR is Fedora's community build service. It compiles source packages in isolated containers and publishes them as ready-to-use RPMs. The workflow mirrors Ubuntu's PPAs but stays within the DNF ecosystem. You enable a COPR project, and DNF treats it like any other repository.
Here's how to enable a COPR repository and install a package from it.
sudo dnf copr enable username/project-name
# fetches the .repo file from copr.fedorainfracloud.org
# creates /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:username:project-name.repo
# imports the project's GPG key automatically
sudo dnf install package-name
# pulls the package from the newly enabled COPR repo
# resolves dependencies against both Fedora defaults and the COPR metadata
To disable a COPR repository later, you run the disable command. The .repo file remains on disk but gets marked as inactive. DNF ignores it during normal transactions.
sudo dnf copr disable username/project-name
# sets enabled=0 in the generated .repo file
# prevents accidental package pulls from that project
# leaves the file intact for future re-enabling
COPR projects vary in quality. Some are maintained by upstream developers. Others are personal experiments. Check the project page before enabling it.
Verify the project status before trusting it with production workloads.
Method 3: Add a .repo file manually
Some projects do not ship an RPM. They provide a raw .repo URL or expect you to create the configuration file by hand. You can add the repository directly through DNF's config manager, or write the file yourself.
Here's how to add a remote repository URL using the config manager.
sudo dnf config-manager --add-repo https://example.com/project/fedora.repo
# downloads the remote file and saves it as /etc/yum.repos.d/example.repo
# automatically generates a unique repository ID based on the filename
# does not import GPG keys unless the .repo file specifies them
If you prefer full control over the configuration, create the file manually. DNF reads any .repo file in /etc/yum.repos.d/. The syntax follows standard INI formatting with DNF-specific variables.
Here's how to write a minimal, secure .repo file by hand.
[myproject]
name=My Project Repository
baseurl=https://example.com/repo/fedora/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://example.com/repo/RPM-GPG-KEY-myproject
# $releasever substitutes your Fedora version automatically
# $basearch substitutes x86_64, aarch64, or ppc64le
# enabled=1 activates the repository for all transactions
# gpgcheck=1 forces cryptographic verification of every package
# gpgkey points to the public key used to sign the packages
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. DNF will overwrite /usr/lib/ files during package updates.
Save the file and refresh the metadata cache before installing anything.
Import a GPG key manually
Some repositories separate the key distribution from the .repo file. If DNF complains about missing keys during installation, you need to import the public key into the RPM database.
Here's how to import a GPG key directly from a remote URL.
sudo rpm --import https://example.com/repo/RPM-GPG-KEY-myproject
# downloads the ASCII-armored public key
# stores it in /var/lib/rpm/gnupg/
# makes the key available to DNF for signature verification
Always verify the key fingerprint against the project's official documentation. A mismatched key means someone intercepted the download or the project rotated their signing key without notice.
Trust the package manager. Manual file edits drift, snapshots stay.
List and manage configured repos
You need visibility into what DNF is actually using. The repolist command shows every configured repository and its current state.
Here's how to list all repositories and filter by status.
dnf repolist all
# displays enabled and disabled repositories
# shows the repository ID, name, and package count
# runs without sudo because it only reads configuration
To disable a repository temporarily for a single transaction, use the --disablerepo flag. This is useful when you need to install a package from the default repos but want to avoid a conflicting third-party version.
sudo dnf install package --disablerepo=myproject
# ignores the myproject repository for this command only
# falls back to Fedora defaults and other enabled repos
# leaves the permanent configuration untouched
To disable a repository permanently, use the config manager. The .repo file stays on disk but gets marked inactive.
sudo dnf config-manager --set-disabled myproject
# changes enabled=1 to enabled=0 in the .repo file
# prevents DNF from fetching metadata on future runs
# allows quick re-enabling without recreating the file
To remove a repository entirely, delete the configuration file. DNF will stop tracking it immediately.
sudo rm /etc/yum.repos.d/myproject.repo
# removes the file from the configuration directory
# clears the repository from DNF's internal state
# requires a metadata refresh to update the package cache
Run dnf clean all after removing repositories to purge stale metadata.
Verify it worked
DNF caches repository metadata in /var/cache/dnf/. You need to confirm the new repository appears in the cache and that DNF can fetch package lists without errors.
Here's how to verify the repository is active and populated.
sudo dnf makecache
# forces DNF to download fresh metadata from all enabled repos
# stores compressed repository data in /var/cache/dnf/
# reports success or failure for each repository
Check the output for your repository ID. A successful run shows the number of packages and metadata size. If the repository fails, DNF prints a clear error and skips it.
Here's how to confirm the repository shows up in the active list.
dnf repolist | grep myproject
# filters the enabled repository list
# confirms the repository ID matches your configuration
# shows the package count DNF successfully indexed
If the repository appears and the package count is greater than zero, the configuration is correct. You can now install packages normally.
Run dnf repolist before every major installation. Half the time the symptom is a disabled or expired repository.
Common pitfalls and what the error looks like
Third-party repositories fail for three main reasons: broken URLs, expired GPG keys, or mismatched architecture variables. DNF refuses to proceed when any of these conditions trigger.
The most common failure is a missing or revoked GPG key. DNF prints a hard error and aborts the transaction.
Error: GPG check FAILED
Failing package is: package-name-1.0-1.fc40.x86_64
From repository: myproject
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-myproject
The error means DNF cannot verify the package signature. Do not disable GPG checks to bypass it. Import the correct key or remove the repository. Disabling signature verification exposes your system to tampered packages.
Another frequent issue is a repodata/repomd.xml 404 error. This happens when the baseurl points to a directory that does not contain DNF metadata.
Failed to download metadata for repo 'myproject': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
The repository maintainer likely changed the directory structure or forgot to run the metadata generation script. Check the project's documentation for the correct URL. Replace baseurl with metalink or mirrorlist if the project provides them.
Variable substitution failures also break repositories. If you hardcode $releasever to a specific number and upgrade Fedora, DNF will look for a path that no longer exists. Always use $releasever and $basearch unless the project explicitly requires static paths.
SELinux denials occasionally block DNF from reading new repository files. Check the audit logs if DNF claims a repository is missing but the file exists.
sudo ausearch -m avc -ts recent | grep yum
# searches the audit log for SELinux denials related to DNF
# shows the exact file and permission that was blocked
# helps you restore context with restorecon if needed
Read the actual error before guessing. DNF tells you exactly which file failed and why.
When to use this vs alternatives
Use RPM Fusion when you need proprietary codecs, graphics drivers, or widely adopted third-party software that follows Fedora's release cycle. Use COPR when you want bleeding-edge versions of open-source tools that are not yet in the main repositories. Use a manual .repo file when a vendor provides a static package feed without an RPM installer. Stick to Fedora's default repositories when you only need standard system utilities, programming languages, or server daemons. Trust the package manager. Manual file edits drift, snapshots stay.