Conflicting files in pacman (Arch Linux)

Occasionally you might attempt to install something using Arch Linux and have it complain about conflicting files. The result is you won’t be able to install whatever it is you’re installing, and you won’t be able to update your system. The remedy for this is rather simple, although care must be taken to ensure that the conflicting packages aren’t owned by anything else. The error will list the path of the conflicting files. Something like this:


Do this :

pacman -Qo /path/to/file

And ensure that the files aren’t owned by anything else. (it will blatently tell you whether or not they are). You can then go and either rename or delete the files it’s complaining about, and then reinstall the package, along with updating your OS :

pacman -S <package-name> && pacman -Syyu

Just something I ran into earlier that was giving me grief, so I figured I’d let you all know how I solved it.

1 Like

That does not make sense to me?
Did you omit something?

no, but basically it’ll tell you a whole bunch of files are conflicting, and it lists them that way. like for example, when I had the issue it was complaining about the electron package, so it would just list all files related to electron. I didn’t have the actual error in front of me when I was writing this, so I basically just went from memory on generally how it looks.

I have not used pacman,
I have never seen that ‘conflicting files’ message in apt or xbps or portage.

Is it telling you the file names of files installed from two packages clash?
I would have thought the distro makers should fix such things.

1 Like

According to the Arch Wiki, it would be something like :

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.

The docs say that if you do :

pacman -Qo /path/to/file

and it says the package is owned by something else, you should file a bug report. It’s built into Arch by design that it won’t overwrite files, so that’s why you probably haven’t seen it elsewhere. It’s due to a metadata file related to the package getting corrupted and that’s why that happens.

1 Like

So what happens in apt or xbps or portage?
Is it so well managed it never happens, or does it just silently overwrite files?

not sure about xbps and portage, but apt just breaks…

I know what happens in portage, it masks packages that clash, so you cant emerge them
Never had a clash in xbps. It is very reliable

1 Like

Theoretically 2 packages in a package system should never contain the same file.
That is the whole point of a package system… you only install any library or whatever once, and all packages share it.
If 2 or more packages share a library, it should become a dependency, ie an independent package.
The only files that should be in a package are those unique to the package.
If distro makers break that, they are breaking the rules of packaging.

A reliable package system is mission critical… almost as important as a reliable filesystem

you know, I kinda want to test this in debian/ubuntu, but I’m not even sure how I’d get this to occur. I’m not even 100% sure how I made it happen earlier in pacman. lol

Find or build a package that contains a library that is already installed by some other package.
It could be someting simple like one library file
There is info somewhere? on how to put together a .deb file
The apt-file command will tell you what files a package makes.

So I created 2 .deb files to test this … one was called hello_1.0-1_arm64 and the other was called goodbye_1.0-1_arm64 :

root@localhost:~# ls
goodbye_1.0-1_arm64  goodbye_1.0-1_arm64.deb  hello_1.0-1_arm64  hello_1.0-1_arm64.deb

They both had the exact same contents. A control file in the DEBIAN directory, along with a control.tar.xz and a data.tar.xz file in /usr/local/bin

root@localhost:~# dpkg -i hello_1.0-1_arm64.deb
Selecting previously unselected package hello.
(Reading database ... 75866 files and directories currently installed.)
Preparing to unpack hello_1.0-1_arm64.deb ...
Unpacking hello (1.0) ...
Setting up hello (1.0) ...

As expected …

So what happens when I try to dpkg -i goodbye_1.0-1_arm64.deb ??

root@localhost:~# dpkg -i goodbye_1.0-1_arm64.deb
Selecting previously unselected package goodbye.
(Reading database ... 75870 files and directories currently installed.)
Preparing to unpack goodbye_1.0-1_arm64.deb ...
Unpacking goodbye (1.0) ...
dpkg: error processing archive goodbye_1.0-1_arm64.deb (--install):
 trying to overwrite '/usr/local/bin/control.tar.xz', which is also in package hello 1.0
Errors were encountered while processing:

It tries to unpack the contents of goodbye over hello, realizes that they’re the exact same thing, and fails. This is on Ubuntu 23.04…

That is a great test.
It seems to say /usr/local/bin/control.tar.xz itself is to be overwritten, rather than the file(s) it would install.
What is it doing in /usr/local/bin? That is a strange place to unpack a .deb file?I never see any tarfiles in /usr/local/bin?

Anyway the main point is, it detects the problem. I think all debian based systems would do the same. dpkg is the same everywhere.

1 Like

Was just an arbitrary thing… Wasn’t any rhyme or reason to it, I just wanted some kind of a directory structure, and that was the first thing I thought of last night lol

1 Like