Arch Linux

KnutKowalski

Member

Registered: 2023-12-11

Posts: 5

Question about Failed to commit transaction (conflicting files) error

Hello! Yesterday I had the following problem when updating via (sudo pacman -Syu)

(Don't be surprised by the German error message, as I'm using a German arch)

"Fehler: Der Vorgang konnte nicht durchgeführt werden (In Konflikt stehende Dateien) qqc2-desktop-style5: /usr/share/locale/ca/LC_MESSAGES/qqc2desktopstyle_qt.qm existiert im Dateisystem (gehört zu qqc2-desktop-style)"

About ten other files from different language folders were affected, which I won't list any further.

I then searched for the problem and found a solution on the Arch Wiki (see below).

I then renamed the files individually and started the update again. The update then went through without any errors and everything has been ok since then.

But now I have a question: Why doesn't pacman simply overwrite these files? I'm not doing anything different by renaming it and the file is no longer available to the system after renaming. Pacman also has the rights to overwrite them (and yes, I read on the wiki that you can force the overwrite, but why do I have to command this manually?).

https://wiki.archlinux.org/title/Pacman … 9.22_error

3.1 "Failed to commit transaction (conflicting files)" error

If you see the following error: [1]

error: could not prepare transaction
error: failed to commit transaction (conflicting files)
package: /path/to/file exists in filesystem
Errors occurred, no packages were upgraded.

This is happening because pacman has detected a file conflict, and by design, will not overwrite files for you. This is by design, not a flaw.

The problem is usually trivial to solve (although to be sure, you should try to find out how these files got there in the first place). A safe way is to first check if another package owns the file (pacman -Qo /path/to/file). If the file is owned by another package, file a bug report. If the file is not owned by another package, rename the file which "exists in filesystem" and re-issue the update command. If all goes well, the file may then be removed.

If you had installed a program manually without using pacman, for example through make install, you have to remove/uninstall this program with all of its files. See also Pacman tips#Identify files not owned by any package.

Every installed package provides a /var/lib/pacman/local/package-version/files file that contains metadata about this package. If this file gets corrupted, is empty or goes missing, it results in file exists in filesystem errors when trying to update the package. Such an error usually concerns only one package. Instead of manually renaming and later removing all the files that belong to the package in question, you may explicitly run pacman -S --overwrite glob package to force pacman to overwrite files that match glob.
Warning: Generally avoid using the --overwrite switch. See System maintenance#Avoid certain pacman commands.

Scimmia

Fellow

Registered: 2012-09-01

Posts: 13,726

Re: Question about Failed to commit transaction (conflicting files) error

I then renamed the files individually and started the update again. The update then went through without any errors and everything has been ok since then.

But now I have a question: Why doesn't pacman simply overwrite these files? I'm not doing anything different by renaming it and the file is no longer available to the system after renaming. Pacman also has the rights to overwrite them (and yes, I read on the wiki that you can force the overwrite, but why do I have to command this manually?).

Because overwriting is COMPLETELY the wrong thing to do in this case. Pacman stops to let you figure out what to do, and the wiki made it clear that it's a process, not just 'run this command'.

The problem is usually trivial to solve (although to be sure, you should try to find out how these files got there in the first place). A safe way is to first check if another package owns the file (pacman -Qo /path/to/file). If the file is owned by another package, file a bug report.

This is the part that applies to your situation. It doesn't say to use --overwrite, does it.

So now you've got files owned by two different packages. When one of them is fixed to remove the conflict, the file will be totally removed from the filesystem and one or both packages on your system could become non-functional. You'll need to reinstall the other one as well at that time.