Manjaro Upgrade Process: Conflicting files and how to deal with them



Now and then Arch fixes something or changes something in its packages and then “require intervention on this upgrade”. Down the road this also will hit Manjaro and thats kind of a bad situation, because not all of our users are on the forums or even want to deal with that and I can fully understand it, because at those moments I’m also upset every single time.

We need to find a good solution for this.

Right now we workaround this by firing up manjaro-release, that deletes the pacman lock file, and forcefully call pacman inside a running pacman session. On all of my systems this wasnt working and it’s also not a good solution to remove the lock file or to call pacman at all.

So the rules are something like …

  • no pacman/libalpm-frontend inside a running update
  • no pacman --force at all
  • no point where the upgrade itself could fail (like dependency circles, usage of the SyncFirst option, need of active internet while the upgrade is running, etc)

Test case
Install Testpkg-0.1-1-any.pkg.tar.xz, now try to install Testpkg-0.1-2-any.pkg.tar.xz. It’ll fail because of

error: failed to commit transaction (conflicting files)
Testpkg: /etc/testing exists in filesystem

pacman -Qo /etc/testing
error: No package owns /etc/testing

Now how to install/upgradeTestpkg-0.1-2-any.pkg.tar.xz, without the need of the user itself?

[Unstable Update] 2018-05-18 - Kernels, Mesa, Xorg-server, Video drivers, Libinput, Gstreamer

How did /etc/testing get created?

Did it come from a manual action?
Was it created by the old version: Testpkg-0.1-1?
Was it created by some old AUR package?

Is this a packaging error because Testpkg-0.1-1 was not listed as the package that “owned” /etc/testing?

Is it a packaging error because Testpkg-0.1-2 was not listed as an upgrade to package Testpkg-0.1-1?

Is this a fundamental limitation of pacman knowing which package is an alternative to some other package? (rpm knows this kind of thing - does Pacman?)

(Sorry, not digging through your packages to figure this all out, - you no doubt have the answers on the tip of your tongue).



Pacman knows file that are inside a package. If a file is created by a post-install-script pacman does not know about it. Also if a file is created by someone outside and this same file is now also in an package, pacman will conflict that file. So updates will fail.

Not at all. I dont have a “good enough” solution for this, but it is a so important thing to have working updates - we should not ignore this.


Well, I see your point, but the problem seems to be a packaging error in the OLD package, which created a critical file, post install, rather than providing it as an empty/default inside the package.

Had that not happened, it would be easy to determine that this was an upgrade and the NEW package could do the usual things ( like creating alternate named files: /etc/testing.pacnew for example).

You see this approach a lot, but I don’t know if that requires that Testpkg-0.1-2 be listed as an upgrade for Testpkg-0.1-1, or what.

The method clearly exists to put files delivered via packages under new names and throw a warning.
But is that the right thing do do?


Exactly one of the problems.

Of course it does. Think of it as regular update, with this issue. Something like the gimp update from 2.8 to 2.10 with this conflicting file. It’s just a test case. Now we need to figure out how to make this update work without interrupting the process.

No. In this case we do want to replace the old file


I’m relatively new to creating packages for pacman but could you not use a pre_upgrade() hook to remove or rename the directory if it exists?


IIRC pacman now has a flag for this. Check pacman help.


Still, thats not a fix. as long as we need to tell the users what to do, it’s not fixed


I thought that was done with manjaro-system release when needed.


Thats the reason why I ask for in the first place, because I really want to get rid of it.