You shouldn’t need all of that. Just sudo dnf remove wine*, then sudo dnf system-upgrade download --releasever=43, then reinstall wine after it’s done. That should be enough.
1 Like
If I try to remove Wine it wants to remove 3 Gigabytes of data total…
that might be right, wine’s quite big. don’t worry about the size so much as the packages themselves. if any of them look like something you don’t want to lose, don’t do it. you can paste the list here if you like and we’ll look it over…
Apologies if this has been answered already, but if one doesn’t want to remove wine before upgrading, this will be fixed at some point via a package update to wine, correct?
It should be, yes.
2 Likes
One workaround that solved it for me was shown in post 14 above.
Worked for me. Thanks
My two cents.,
I’ve got the same message:
- Remove the conflictive package with no dependencies in this way:
-
sudo rpm -e wine-core-10.15-1.fc42.x84_64 --nodeps -
sudo dnf system-upgrade download --releasever=43 --allowerasing --best
Regards.,
1 Like
Hey, how are you?
Welcome back!!
Please don’t recommend this. There is a high chance it could cause people to run into 2408378 – Offline system update crashes in libdnf::Swdb::setItemDone/libdnf::TransactionItemBase::setState , which is a much worse bug that can leave the system unusable. Please stick with the safe workaround of removing all wine packages before upgrading.
I see lots of “just uninstall wine and re-install it after” … but… what about the missing 32-bit wine packages in F43? .. You can’t re-install it after the upgrade because some packages aren’t there!
That isn’t a “work-around”, it’s a “just remove these packages and ignore the fact you will want them after the upgrade”.
How on earth did F43 get past a stopper like this?
When I updated from f42 to f43 I ran into the same problem.
My solution, which was much less extreme than the suggested ‘remove wine totally’, was to simply remove the wine-core.i686 package, which eliminated all the conflicts about wine. I did the upgrade then was able to reinstall the wine-core.i686 package and things worked.
The answer to that question is likely unsatisfiable, somewhere between “nobody complained loudly enough about it” and “it might not have been considered a bad enough issue to prevent the release even if somebody had complained loudly” 
Well I guess it’s a “wait and see if F43 gets the 32-bit libraries”.
Still no idea why the 32-bit RPMs were not built… The 64-bit library packages have the 64-bit path, so it’s not path conflicts.
It’s just someone brainlessly decided not to build the 32-bit dxvk packages.
This looks like what happened here: https://src.fedoraproject.org/rpms/wine-dxvk/c/ef1496d (note the ExclusiveArch change to remove i686`).
I’m not sure why this was done. Maybe it was a misunderstanding of what I asked for in this bug report? https://bugzilla.redhat.com/show_bug.cgi?id=2393888
You might want to report a bug about the missing wine-dxvk i686 builds in case they’re really still needed on Fedora 43+.
1 Like
Thank’s very much for that, I’ll jump on that where/if I can.
I totally forgot that Wow64 was a thing (I seem to recall seeing a few Phoronix articles a while back).
So I guess we shouldn’t “require” 32-bit libraries anymore (if we set the WINEARCH=wow64 environment variable).. Although those running 32-bit Fedora and running wine may run into an issue where the dxvk libraries are missing and may be moaning.
Thanks for the pointer about Wow64 mode, I’ll definitely use that and report any issues for that.
That should be zero people. Fedora hasn’t supported i686 as a full architecture since Fedora 31.
1 Like
There is though, the consideration that many are using steam, which is 32 bit and requires many x86_32 packages as dependencies.
The wine-dxvk-* packages are all available in x86_64 arch packages for f43. Supposedly the new version of wine with x86_64 arch for f43 is able to run the 32 bit apps as well.
(post deleted by author)