You need a package that isn't in the official repos
You have a tool that works on your machine, but installing it on a second laptop required copying three libraries and fixing a path error. You tried compiling from source, but the dependencies drift between Fedora 40 and 41. You need a way to share this package with your team or install it cleanly on a new system without fighting dnf errors. You don't want to set up a private build farm, and you don't want to maintain a static tarball.
COPR is the bridge between your spec file and a working package manager. It lets you build RPMs in a Fedora-hosted environment and distribute them through a repository that dnf understands. You get reproducible builds, dependency resolution, and easy installation without buying hardware or configuring mock.
What COPR actually does
COPR stands for Community Projects Repository. It is a hosted build service run by the Fedora Project. You provide a spec file or a source RPM. COPR takes that file, spins up an isolated chroot environment matching the target Fedora release, runs the build, and publishes the resulting RPMs to a repository URL.
Think of COPR as a print-on-demand service for packages. You send the manuscript, COPR prints the books, and puts them on a shelf you can subscribe to. The build environment is clean. It does not inherit your local packages or configuration. If the build succeeds on COPR, it will succeed on any machine running that Fedora release with the same architecture.
COPR projects are public by default. Anyone can see your build logs and install your packages. Use COPR for testing pre-release versions, distributing tools for a specific community, or hosting packages that are too niche for the official Fedora repositories.
Prepare the source RPM locally
COPR accepts source RPMs or spec files hosted in a SCM. The most reliable workflow is to build the SRPM locally first. This catches syntax errors in your spec file before you consume COPR build resources. Fedora developers use a standard directory structure to keep builds organized. Set up your local build tree so the tools know where to look.
# Install the development tools needed to create SRPMs and download sources
sudo dnf install rpmdevtools spectool
# Initialize the standard directory structure under your home folder
rpmdev-setuptree
# Copy your spec file into the SPECS directory where rpmbuild expects it
cp mypackage.spec ~/rpmbuild/SPECS/
# Download all source files listed in the spec into the SOURCES directory
spectool -g -R ~/rpmbuild/SPECS/mypackage.spec
# Build the source RPM without compiling binaries yet
rpmbuild -bs ~/rpmbuild/SPECS/mypackage.spec
Build the SRPM first. A broken spec file wastes COPR resources and your time. Fix errors locally until rpmbuild -bs produces a clean SRPM in ~/rpmbuild/SRPMS/.
Submit a build to COPR
You can upload builds via the web interface or the command line. The CLI is faster for automation and scripting. Install the COPR client and authenticate with your Fedora Account System credentials.
# Install the COPR command-line interface
sudo dnf install copr-cli
# Authenticate and generate an API token linked to your FAS account
copr-cli login
# Submit the SRPM to your project for building on the COPR infrastructure
copr-cli build <username>/<project> ~/rpmbuild/SRPMS/mypackage-1.0-1.fc41.src.rpm
Use the CLI for repeatable workflows. The web UI is for quick tests. The build will appear in the queue on the COPR project page. You can watch the progress and download the logs if the build fails.
Automate builds with Packit
Manual builds work for one-off packages. If you maintain a project on GitHub, Packit integrates COPR builds into your pull request workflow. Packit watches your repository and triggers COPR builds automatically. This lets reviewers and testers install pre-release packages without building locally.
Add a .packit.yaml configuration file to your repository root. Packit reads this file to know how to build and where to submit the results.
# Define the package names for upstream and downstream
upstream_package_name: mypackage
downstream_package_name: mypackage
specfile_path: mypackage.spec
jobs:
# Trigger a COPR build whenever a pull request is opened
- job: copr_build
trigger: pull_request
targets:
# Build for specific Fedora releases and architectures
- fedora-41-x86_64
- fedora-rawhide-x86_64
Packit submits the build to COPR and posts a comment on the pull request with the repository URL. Contributors can enable the repo and test the package immediately. This reduces the friction for testing and speeds up the review cycle.
Enable the repository on target machines
Once the build finishes successfully, the repository is ready. Enable it on the target machine to make the package available to the package manager. The dnf copr plugin handles the repository configuration automatically.
# Enable the COPR repository and download the repo metadata
sudo dnf copr enable <username>/<project>
# Install the package from the newly enabled repository
sudo dnf install mypackage
Enable the repo on the target machine. The package manager handles the rest. The repository configuration is stored in /etc/yum.repos.d/. You can edit or remove this file manually if needed, but using dnf copr disable is safer.
Manage repository priority
COPR repositories do not override official Fedora packages by default. dnf prefers packages from the official repositories. If a package exists in both COPR and the official repos, dnf will install the official version unless you change the priority. This protects your system from accidental downgrades or conflicts.
Check the priority of the COPR repository to understand how dnf resolves conflicts.
# Check the priority of the COPR repository
dnf repoquery --queryformat='%{name} %{priority}' copr:<username>/<project>
COPR repos usually have a priority of 99, while official repos have 98. Lower numbers mean higher priority. If you need the COPR package to take precedence, you can adjust the priority in the repo file. Be careful with this. Forcing a COPR package over an official one can break dependencies if the versions diverge.
Verify the installation
Confirm the package came from COPR and not a local cache. Check the build host and version information.
# Query the installed package to confirm the build host and version
rpm -qi mypackage
# List all enabled repositories to ensure the COPR repo is active
dnf repolist
Check the build host. If it says localhost, you installed a local file, not the COPR package. If it says copr-be.cloud.fedoraproject.org, the package was built by COPR.
Common pitfalls and error patterns
Builds fail when the spec file references a dependency that isn't available in the target chroot. COPR runs builds in a clean environment. It does not inherit your local packages. If the build log shows RPM build errors: Installed (but unpackaged) file(s) found, your spec file is missing a %files entry. You built a file but didn't tell RPM to include it.
If you see No match for argument: python3-some-lib, that library is not in the Fedora repos for that release. Check the build logs on the COPR project page. The logs are the source of truth. Never guess from the summary. Scroll to the end of the log. The actual error is usually three lines before the final failure message.
Another common issue is architecture mismatch. COPR builds for the architectures you select in the project settings. If you enable the repo on an ARM machine but only built for x86_64, dnf will report no packages available. Ensure your project targets the correct architectures.
Read the full build log. The error message is usually three lines before the summary. Fix the spec file and rebuild.
When to use COPR versus other options
Use COPR when you need to distribute packages to a small group or test a pre-release version before submitting to Fedora.
Use the official Fedora repositories when the package is stable, meets packaging guidelines, and should be available to all users.
Use RPM Fusion when you need proprietary codecs or drivers that cannot be included in Fedora due to licensing restrictions.
Build locally with mock when you are debugging a spec file and need immediate feedback without waiting for the COPR queue.
Stay on manual installation when the tool is a single binary with no dependencies and you only run it on one machine.
Pick the tool that matches your distribution scope. COPR is for community and testing, not for production stability guarantees.