Also got this issue when upgrading from F42 to F43. I had to uninstall the package wine-core first, before upgrade was possible. Wine and all dependencies will be removed.
After the upgrade was done, I had to reinstall all of my wine packages, wine wine-mono winetricks protontricks. The package wine-core was installed together with the other packages.
Do you have both 32-bit and 64-bit WINE installed?
I didnât install 32-bit and 64-bit separately. Every time I installed Wine, I did this installation:
sudo dnf install wine wine-mono winetricks protontricks
My wine was installed via Lutris⌠few years back you had to install wine separately.
Iâm using Lutris also. But I install Wine and its dependencies before installing Lutris.
There is often small issues on upgrading that will get fixed in time.
The usual work around is to uninstall the conflicting packages as @denalb said.
Either wait for the RPMs to be updated or remove wine, upgrade, reinstall wine.
What is the point of -âallowerasing if it does not remove conflicting packages like this and makes a note of it at the end?
If you installed wine on Fedora <43, you got both wine-core.x86_64 and wine-core.i686. On Fedora 43, the latter is no longer ânecessaryâ since Wine on Fedora 43+ is built in ânew WoW64 modeâ which doesnât require a 32-bit Linux userspace for running 32-bit Windows applications. Upgrading with --allowerasing should work, I think âŚ
That said, the issue about this preventing successful upgrade to Fedora 43 is tracked in this ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2401666
If --allowerasing does the necessary, great, but otherwise I know that the uninstall, upgrade, install workflow usually works.
If you think that there is a bug with --allowerasing please report it.
âallowerasing did not work, I needed to remove wine. Reminds me of RHEL Leap.
Ok. This should explain the behavior.
No. It didnât work for me. It didnât solve the conflict by itself. But itâs ok for me because after removing and reinstalling everything is fine. 
I just checked and the problem appears to be having both wine-core.i686 and wine-core.x86_64 installed when the upgrade is attempted.
There is a simple workaround that works for me.
- remove wine-core-i686
- upgrade
- reinstall wine-core.i686
Although the info I have seen says the wine-core.i686 should no longer be necessary since there has been a change in the x86_64 package that allows those file to run the 32 bit apps.
I have not tested this last bit of information.
--allowerasing will only âworkâ if the issue requiring some package to be omitted is apparent to dnf during the first stage of resolution, where it decides the packages in the transaction, I think. undeclared file conflicts are only discovered later, once the set of packages in the transaction has been decided, which is 'too late` for it to kick in. I think thatâs why itâs not working here, anyway.
I ran into this today as well.
The workaround seems to work for me.
I wonder if the change in the package that allows the 64bit package to be used with 32bit apps is what has caused this hiccup. Iâd need to examine what the specific file conflicts are, but my gut says thatâs what is happening.
The bug has details. @mooninite is already planning to work on it, he just didnât get to it yet by the looks of it.
Worked for me:
sudo dnf remove wine* -y
sudo rm -rf /usr/lib/wine /usr/lib64/wine
sudo dnf clean all
sudo dnf autoremove -y
sudo dnf system-upgrade download --releasever=43
Might wait for Fedora to get around to fixing it cause it keeps failing.
Would be nice if we didânt have to redownload everything when the transaction fails⌠3.7GB of data can be stored somewhere and it wont be a problem.
copy & paste from Upgrading Fedora Linux Using DNF System Plugin :: Fedora Docs
If you want to remove/install some packages manually before running
dnf system-upgrade downloadagain, it is advisable to perform those operations with--setopt=keepcache=1dnf command line option. Otherwise the whole package cache will be removed after your operation, and you will need to download all the packages once again.