File conflicts when installing two packages at the same time, but not when installing one at a time

[ericonr]

Tested this on a new chroot, x86_64.

Installing the packages breeze and breeze-snow-cursor-theme separately, in any order, works. Trying to install both at the same time (same xbps-install command) doesn't work, due to error messages like

[ERROR] breeze-5.18.5_1: file `/usr/share/icons/Breeze_Snow/cursors/xterm' already installed by package breeze-snow-cursor-theme-1.0_1

I think this error is correct, in that those files do conflict (there is a packaging error here), the issue is that when the commands are run separately, XBPS doesn't check that one is overwriting the other.

[ericonr]

I installed breeze then breeze-snow-cursor-theme. Uninstalling the latter and force reinstalling the former led to error messages

[ERROR] breeze-5.18.5_1: failed to remove obsolete entry `./usr/share/icons/Breeze_Snow/cursors'

The command exited with a success code as well. Force reinstalling for the second time resulted in the expected "removed obsolete entry" messages.

[Duncaen]

Yes this is known, currently all package files are stored in separate files in /var/db/xbps/*-files.plist. When I added the file conflict check, I choose to not read all the files because this would slow everything down a lot and would require a lot more memory.

I think to get a global file conflict check, we need to add a better files database, that doesn't require to read N (number of installed packages) files and optimally as a tree to reduce the memory overhead.

[ericonr]

Do you have some work on that, already? Or some more defined ideas regarding the architecture? Could be interesting to tackle.

[Duncaen]

xbps only detects file conflicts in transactions since less then a year https://github.com/void-linux/xbps/pull/121, we always just relied on packagers checking for conflicts (which didn't work that well and is the reason why xtraeme added --ignore-file-conflicts to xbps-install).

I played around with some ideas but nothing concrete yet.

[pullmoll]

There is one known (to me) way to produce packages with conflicting files. It happens when a package has a archs=noarch subpackage which is already in the index, while the package itself is still to be build.

I saw this happening when I used xbps-rindex -a kbd-data-2.2.0_1.noarch.xbps at some point and only later built kbd. In that case the kbd-data_package() subpackage is skipped and the data files which would have been vmoved remain in the main package kbd. Trying to install kbd then fails with conflicting files between kbd and kbd-data. D'OH!

Ok, this was my fault to add kbd-data-*.noarch.xbps in the first place, but then this problem may bite people trying to avoid needless building of noarch packages or trying to get their repository in shape after force-building a package which has a archs=noarch subpackage. We all know that force building breaks noarch packages for other architectures in the same repo.