Finding which package a file belongs to
Two axes answer nearly every file question about a package: whether you are asking about this machine or about the repositories, and whether you are starting from a path or from a package name. Four commands sit at the four corners.
pacman -Qo /usr/bin/ls-Q- --query — ask the local database about packages that are already installed
-o- --owns — print which installed package owns the given file
Runs without root.
What it does. Name the installed package that owns a path on this machine.
Watch out. If no installed package owns it, the file arrived from somewhere other than pacman, and that is worth knowing before anything overwrites it.
The four corners
| Command | Question it answers | Root? | Level |
|---|---|---|---|
pacman -Qo /usr/bin/ls | Which installed package owns this path | no | routine |
pacman -Ql firefox | What did this installed package put on disk | no | routine |
pacman -F ls | Which package in a repository carries a file with this name | no | routine |
pacman -Fl firefox | What would this repository package put on disk | no | routine |
sudo pacman -Fy | Download the file databases that -F reads | yes | routine |
The last row is the exception that catches people. Asking -F a question only
reads, but the databases it reads are a second set that is not downloaded with an
ordinary upgrade. Until -Fy has been run once, -F answers nothing.
Starting from a path you already have
-Qo takes a path and names the package. It works on paths that exist, and it is
the command to reach for when pacman refuses an install because a file is in the
way.
pacman -Qo /usr/bin/ls/usr/bin/ls is owned by <package> <version>The shape of the answer. When nothing owns the path, pacman says so, and that answer is the useful one: the file came from outside pacman.
That second case is exactly the one behind a conflicting files message. The error message page has the entry for it.
Starting from a package
-Ql lists what an installed package put on disk. It is long for anything with
documentation, so it is usually paired with a filter:
pacman -Ql firefoxpacman -Ql firefox | grep /usr/bin/A pipe rather than a single pacman command, so no level is given: what grep does with the list is outside pacman.
The related question, whether the files a package owns are still the files on disk, has its own modifier:
pacman -Qk firefoxChecks the files this package owns against the local database. A doubled k checks them more thoroughly.
Asking about packages that are not installed
-F answers from the repository file databases, so it can tell you which
package to install to get a command you do not have yet. That makes it the useful
half of the pair when a command is missing rather than broken.
sudo pacman -FyDownloads the file databases into /var/lib/pacman, which is why this one writes and the rest of -F does not.
pacman -F lsThe file databases are refreshed by -Fy rather than by an ordinary upgrade, so
on a machine that has not run it they are either missing or old. Running it again
is cheap.
Common questions
How do I find which package owns a file on Arch Linux?
Run pacman -Qo followed by the path. It answers from the local database, so it covers packages installed on this machine. If nothing owns the path, the file came from somewhere other than pacman.
How do I list the files a package installed?
Run pacman -Ql followed by the package name. For a package that is not installed, pacman -Fl answers the same question from the repository file databases instead.
Why does pacman -F return nothing?
The file databases it reads are a separate set that an ordinary upgrade does not fetch. Running sudo pacman -Fy downloads them, after which -F has something to answer from.
What is the difference between pacman -Qo and pacman -F?
-Qo asks the local database about a path that exists on this machine. -F asks the repository file databases which package would carry a file with that name, whether or not it is installed.