Description of problem: Try to install both 32 and 64 bit packages: elfutils-libelf-0.166-1.fc23.i686 and elfutils-libelf-0.165-2.fc23.x86_64 Version-Release number of selected component (if applicable): up to date f23 How reproducible: dnf install elfutils-libelf-0.166-1.fc23.i686 elfutils-libelf-0.165-2.fc23.x86_64 Or in my case I tried to update the system with those packages already installed. Actual results: dnf gives the following errors: Error: Transaction check error: file /usr/share/locale/de/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/es/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/ja/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/pl/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 file /usr/share/locale/uk/LC_MESSAGES/elfutils.mo from install of elfutils-libelf-0.166-1.fc23.i686 conflicts with file from package elfutils-libelf-0.165-2.fc23.x86_64 Error Summary ------------- Expected results: Both packages should install.
(In reply to Jussi Eloranta from comment #0) > Description of problem: > > Try to install both 32 and 64 bit packages: > elfutils-libelf-0.166-1.fc23.i686 and elfutils-libelf-0.165-2.fc23.x86_64 > > Version-Release number of selected component (if applicable): up to date f23 > > How reproducible: > > dnf install elfutils-libelf-0.166-1.fc23.i686 > elfutils-libelf-0.165-2.fc23.x86_64 You are trying to install different versions (0.166-1 vs 0.165-2). Try installing the same version of the i686 and x86_64 package: dnf install elfutils-libelf-0.166-1.fc23.i686 elfutils-libelf-0.166-1.fc23.x86_64
OK - missed that BUT it does not seem wise for dnf to try to perform the update such that it ends up in such a conflict!!? So, the situation was that both 64 and 32 bit versions of that package were already installed on the system and then I ran update, which now persistently fails because one of the archs does not yet have the package available. I would think that dnf should simply skip such updates rather than stop the whole process (and prevent other updates for being installed).
(In reply to Jussi Eloranta from comment #2) > OK - missed that BUT it does not seem wise for dnf to try to perform the > update such that it ends up in such a conflict!!? Agreed. I don't know how dnf got into this situation in the first place. Lets see what the dnf hackers say (reassigned the bug).
Thanks for the report. This is more complicated topic about knowing what is multilib and what is not. We should agree whether in rpm should be another flag for the multilib identification. If it's multilib then DNF shoudl not permit installing two different versions of the same package.
As of today, the system is still in such shape that it is unable to install updates. I would imagine that the proper versions of the libs would have appeared by now (?) Well, of course, it updates with --exclude=elf\* passed to dnf but I have to do this manually for all the affected computers. An easier solution would be to just think these are broken and skip these. I don't think it needs to even know if it is multilib.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Since the conflicts are just messaging files, I got around this issue by using RPM to force install the offending package (Note: this was Fedora 23): $ sudo rpm -i --replacefiles /var/cache/PackageKit/23/metadata/updates/packages/elfutils-libelf-0.166-1.fc23.*.rpm After that, completing updating the rest of the elfutils worked fine: $ sudo dnf update elf\*
> OK - missed that BUT it does not seem wise for dnf to try to perform the > update such that it ends up in such a conflict!!? Package wise elfutils x86_64 and i686 packages neither do conflict nor require a specific version of each other. So there's no problem to install them in parallel. On the other hand they contain the same .mo files which is not a problem if you install the same version of x86_64 and i686 package (because the files are identical - have the same chackusum). If versions differ so do files (because they contain at least different timestamps) and it (must) generates file conflict. > So, the situation was that both 64 and 32 bit versions of that package were > already installed on the system and then I ran update, which now persistently > fails because one of the archs does not yet have the package available. That's the root cause and it's a broken packaging / release process. Unfortunately nothing dnf or libsolv can fix.
*** Bug 1415142 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I am sorry but I do agree with Michael Mraka that this problem cannot be solved by DNF. I know that it would be nice if solver can handle file conflict, but basically it doesn't have information about checksum of files that is essential to resolve file conflicts. This information is available after downloading of rpms to RPM, that does transaction check. Therefore result is that at that point transaction fails. I am sorry am closing it.
I am sorry but this bug is showing up in a number of other files in F25 and is blocking my upgrade to 26: Error: Transaction check error: file /usr/share/doc/gsm/README from install of gsm-1.0.17-1.fc25.i686 conflicts with file from package gsm-1.0.16-1.fc25.x86_64 file /usr/share/doc/gsm/ChangeLog from install of gsm-1.0.17-1.fc25.i686 conflicts with file from package gsm-1.0.16-1.fc25.x86_64 file /usr/share/doc/libgcrypt/NEWS from install of libgcrypt-1.7.8-1.fc25.i686 conflicts with file from package libgcrypt-1.6.6-1.fc25.x86_64 file /usr/share/doc/libgcrypt/AUTHORS from install of libgcrypt-1.7.8-1.fc25.i686 conflicts with file from package libgcrypt-1.6.6-1.fc25.x86_64 Yes, I see this can be dealt with by deleting the i686 files and thus not requiring something that will conflict, but I just had to remove a kernel for the same reason (4.10.5-200.fc25). This is not a simple single file problem it appears.
Please can you investigate why you cannot have packages for x86_64 and i686 same version? As you can see the problem is with shared files between multiarch packages (docs, AUTHORS ...). Please can you upgrade gsm-1.0.16-1.fc25.x86_64 to gsm-1.0.17-1.fc25.x86_64 ? And other packages also?