You need the package name before you can install it
You are following a tutorial and the instructions say install libssl-dev. You type sudo dnf install libssl-dev and get No matches found. You are on Fedora. The package name is different. Or you are compiling software and the build fails because of a missing header file openssl/ssl.h. The error message gives you a filename, not a package name. You need to find the package that provides that file before you can proceed. dnf has commands for this, but the workflow depends on what information you already have.
What is actually happening
DNF does not query the Fedora servers every time you type a search command. It reads a local database of metadata that describes every package in your enabled repositories. This database lives in /var/cache/dnf/. When you run a search, DNF scans this local cache. If the cache is stale, your search results will be stale. This design keeps the package manager fast and prevents hammering the mirrors. It also means you must refresh the cache if you just enabled a new repository or if the Fedora release is a few weeks old.
dnf upgrade --refresh is the normal weekly maintenance command. It forces a metadata refresh before checking for updates. dnf makecache builds the cache without performing an upgrade. Use --refresh when you suspect the cache is old. You do not need sudo to search. Reading metadata is safe. You only need sudo for install, remove, or makecache.
Search by keyword
Here is how to search package names and descriptions for a keyword.
dnf search ffmpeg
# Queries the local metadata cache for package names and descriptions.
# Returns a list of matches with a short summary line.
# The search is case-insensitive and matches partial strings.
The output lists the package name and a truncated description. If the description is cut off, the package name is usually enough to proceed. You can use wildcards to refine the search. A wildcard * matches any sequence of characters.
dnf search "*python*"
# Uses wildcards to find packages containing "python" anywhere in the name or description.
# Wildcards must be quoted to prevent the shell from expanding them.
# This returns a broader set of results than a plain keyword search.
DNF also supports regular expressions. Use ^ to anchor the search to the start of the string.
dnf search "^python"
# Uses a regular expression to match packages starting with "python".
# The caret anchors the pattern to the beginning of the name or description.
# This filters out packages like "libpython" or "python-devel".
DNF search uses wildcards by default. If you want regex, you must use the --regexp flag or start the pattern with ^. Without ^, DNF treats the pattern as a wildcard. This catches users who expect grep-like behavior.
dnf search --regexp "^python3"
# Forces regular expression matching for the search pattern.
# The caret anchors the match to the start of the string.
# Without this flag, DNF treats the pattern as a wildcard.
Search the metadata, not the internet. The cache is your friend.
List and info
Here is how to check the installation status and available version of a package.
dnf list vim
# Shows the installed version if present, or the available version if not.
# The repository column indicates the source of the package.
# This command reads metadata only and does not modify the system.
The output distinguishes between Installed and Available. If you see Available, the package is in the repository but not on your system. If you see Installed, the package is present. You can filter the list to show only available packages.
dnf list available vim*
# Filters the list to show only packages that are not yet installed.
# Useful for checking what is available without clutter from installed software.
# Wildcards work here too to match multiple package names.
For more detail, use dnf info. This shows the full description, license, size, and changelog.
dnf info vim
# Displays detailed metadata including full description, license, and size.
# Confirms the package exists and is ready to install.
# Look for the "Repo" field to verify the source repository.
Check the repo column. If the package comes from a disabled repo, you need to enable it first.
Find by file path
Here is how to find the package that owns a specific file or library.
This is the most powerful search tool for troubleshooting. When a build script fails because of a missing header, or a program crashes because of a missing shared library, the error message gives you a filename. You need to find which package provides that file. Use dnf provides. The path must be absolute and exact.
dnf provides /usr/bin/ffmpeg
# Searches metadata for the package that installs this exact path.
# Useful when a build error mentions a missing header or binary.
# The path must be absolute and match the metadata exactly.
You can also search for libraries by their soname.
dnf provides libssl.so.3
# Finds the package that provides this shared library soname.
# Essential for resolving dynamic linker errors at runtime.
# The soname must match the metadata entry exactly.
dnf provides also works for man pages and systemd units.
dnf provides man:ffmpeg
# Finds the package that provides the man page for ffmpeg.
# Useful when you want to read documentation but do not have the package.
# The prefix "man:" tells DNF to search man page metadata.
Provide the full path. DNF matches files, not guesses.
Filter by repository
Here is how to limit search results to a specific repository.
This helps when you have multiple repositories enabled and want to know where a package comes from. It also helps when a package exists in multiple repos and you want to prioritize one.
dnf search --repo=rpmfusion-free ffmpeg
# Limits the search to the specified repository.
# Useful when you want to check if a package is available in a third-party repo.
# The repo ID must match the output of dnf repolist.
Common pitfalls
The error No matches found appears when DNF cannot find the query in the metadata. This happens for three reasons. The cache is stale. The package name is wrong. The file path is wrong.
No matches found for: libfoo.so
If you see this error, refresh the cache first.
sudo dnf makecache --refresh
# Downloads fresh metadata from all enabled repositories.
# Overwrites the local cache files in /var/cache/dnf/.
# Run this after enabling a new repo or if search results seem old.
If the cache is fresh, check the spelling. Fedora package names are lowercase and use hyphens, not underscores. libfoo not lib_foo. If you are using dnf provides, check the path. dnf provides ffmpeg fails. You must use dnf provides /usr/bin/ffmpeg.
Another pitfall is module streams. Fedora groups some packages into modules. If a package is part of a module, it might not appear in search results unless the module stream is enabled. Check module status if you suspect this.
dnf module list
# Lists all available module streams and their states.
# Shows which streams are enabled, disabled, or installed.
# Some packages only appear after enabling their module stream.
dnf module list is for modules. dnf search searches packages. Modules are a higher-level abstraction. If you need a specific version of a tool like Node.js or Python, check modules.
Refresh the cache before you blame the package manager. Stale metadata causes half the missing package errors.
When to use each tool
Use dnf search when you have a keyword or partial name and need to find the package. Use dnf list when you want to check installed status and available versions for a known package name. Use dnf provides when you have a filename or library path and need to find the owning package. Use dnf info when you need the full description, license, and changelog before installing. Use dnf repoquery when you need to script complex queries or filter by architecture and version constraints. Use locate or find when you are searching for files already installed on the system, not packages in the repository.
Pick the tool that matches your input. Keyword gets search, path gets provides.