The cause of an odd DNF/RPM error about conflicting files
Recently I updated the kernel on my Fedora desktops and as I usually do, updated to the latest development version of ZFS on Linux. When I did this, I got an error message from DNF (which I think is really an RPM error message) that struck me as impossible:
file /usr/src/zfs-2.1.99/cmd/arc_summary from install of zfs-dkms-2.1.99-1199_g0c11a2738.fc35.noarch conflicts with file from package zfs-dkms-2.1.99-1136_ge77d59ebb.fc35.noarch
Here, I'm updating the zfs-dkms RPM package (among others), or trying to, and DNF is telling me that a file from the new version of the package is conflicting with the same file from an old version of the package.
It's perfectly natural for DNF/RPM to tell you about cross-package file conflicts (although it's not really supposed to happen). What that means is that both RPM packages include a file by that name but with different contents. However, this isn't supposed to happen when you update a package; the old and the new versions of the package may have the same file with different contents, but after the update there's no conflict because the old file (and package) has been replaced with the new file (and package).
(Modern versions of RPM and DNF even handle the case of upgrading multi-arch packages in sync with each other that used to cause problems.)
Unfortunately, this error message is misleading, and specifically it is misleading in its use of 'file'. You and I might think that by 'file', DNF means a Unix file. Actually what it means is a Unix file name, because the actual problem is that in the old package, /usr/src/zfs-2.1.99/cmd/arc_summary was a directory (due to a package building error) and in the new package it is now a file (due to the package building error being fixed). RPM can turn one version of a Unix file into another version of a Unix file during a package upgrade, but it can't 'upgrade' a directory into a file (or at least it won't).
Fortunately there is a simple fix, because what RPM cares about for the old package is what's actually on the filesystem. All you have to do is remove the arc_summary directory in advance (or rename it to something else), and DNF/RPM will be happy. Now that the old package's directory is gone, it doesn't have to try to turn it into a file (which it can't do); it can just put the new file down.
(RPM not being willing to deal with this change of a directory into a file in a new version of the package is probably sensible. But it really should have a better error message, one that gives people an answer about what's going on.)