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:
/usr/bin/file1
/usr/share/file2
/usr/bin/file3
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.
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.
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.
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.
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.
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