I still see both wine-core.x86_64 and wine-core.i686 on Fedora 43. It’s just the upgrade process that is problematic, not a fresh install. So what exact “disastrous” problem are you referring to?
So as someone that just encountered this problem, will this eventually get fixed? I.e. can I wait a few months before upgrading, or will I have to delete Wine if I ever want to upgrade to 43?
@mooninite said in the referred bugzilla that he’s working on it, but it’s probably a difficult problem. Michael, perhaps you can provide an update here or in the bugzilla (somebody asked there as well)? Thanks!
That said, I understand it’s not ideal, but why is anyone hesitant uninstalling wine to perform the upgrade? It’s just RPM packages, they don’t touch your home configuration or anything. If you uninstall wine (if it removes some other tools that depend on it, like perhaps lutris or similar, just note them down), do the upgrade, and install it back (including those extra tools, if applicable), you’re back in the original state. There’s no loss or harm in doing it.
Possibly because trusting that the uninstall / reinstall process won’t touch your personal data/wine programs requires a bit of experience if you’re not familiar with how things work under the hood.
If someone is less familiar with DNF/RPM (and particularly if they’re coming from Windows which historically hasn’t had such a clean system/user split) then I think a bit of caution about the situation is understandable - particularly as this is something that shouldn’t normally happen.
I wonder whether amending the common issue post to explain that would help?
Maybe something like this at the end:
Note that removing the wine packages should not remove any windows programs you have installed - these are usually stored in your home directory. After the Fedora upgrade is complete, reinstall wine (run
sudo dnf install winein a terminal or repeat the installation method you used originally) and then these programs should become usable again.
Not sure what the process is for amending the official descriptions/workarounds?
and particularly if they’re coming from Windows
Yes, exactly. I’ve been a Windows user for 25 years. I decided to switch to Linux a few months ago and I’m still learning ins and outs of Fedora. While I really appreciate all the hard work that went into Fedora, the situation “system update failed because you have installed one of the most essential Linux apps, deal with the problem on your own” is peak “2025 will finally be the year of desktop Linux” meme. It would be really useful if there was at least some “official” workaround that guarantees that nothing will break in the process and no user data will be lost. This is especially important considering the fact that one of the first workarounds that was discussed involved removing some symlinks, which then turned out to break the update process.
What I’m trying to say is that is that desktop Linux is slowly becoming mainstream, which means that it will have more and more non-technical users, which means that usability issues should be getting more priority than they used to. Personally I’m still waiting for some kind of official communication “do this and it will be fine”.
But those are just my two cents, and if my perspective here is wrong, please correct me.
Your perspective isn’t wrong, it’s yours. Just remember that other people have different perspectives and use their computers differently and we’ll all get along fine. Welcome to Fedora!
The “official communication” is the post linked at the top of the thread and its unfortunate that an early workaround wasn’t actually helpful. The instructions it lists now are your solution unless/until the underlying problem with the packages can be fixed to allow upgrades to happen smoothly - sounds like that is still a work in progress.
It’s worth noting that there are no guarantees offered with Fedora (or open source software in general), so the closest you will get is that it’s the solution that’s been chosen to show here and people who can say “it worked for me”.
By way of explanation/reassurance: Any programs have installed with wine live in the .wine folder in your home directory unless you specifically put them somewhere else, and that won’t be touched by the package uninstall and reinstall.
That doesn’t rule out the possibility that something else goes wrong with your update and it doesn’t rule out the possibility that there’s a bug in the newer version of wine that breaks something - but in that case you would have had the same issue after the upgrade anyway, just quicker.
Do I think that’s likely to occur? No.
Am i willing to guarantee that it won’t? Also no.
Would I follow the steps in the current workaround (uninstall, make a list, upgrade system, reinstall)? Yes.
If you aren’t aware, Fedora will support Fedora 42 until a month after Fedora 44 comes out so there’s no immediate rush to upgrade if you’d rather wait and see if another fix is possible. if it isn’t possible to fix the packages to allow a smooth upgrade then you’ll probably need to follow this process in ~6 months time instead as part of the upgrade to F44.
Hope that clarifies things a little?
Makes sense. I didn’t realize that people unfamiliar with Linux aren’t aware of the system vs user data separation. And we’re clearly hitting a lot of that audience with this bug. I updated the common issue description.
I understand your point of view. I would guess that most Fedora users don’t have wine installed, though (I don’t have any data). And if they do, they have it just for games. But among newcomers, it might be much more prevalent, because they might still rely on some windows apps.
We’re unfortunately unable to guarantee that all packages can be upgraded. We’re simply not there yet with our tooling. There are 80 thousand packages in Fedora repos. We do guarantee that the default installation can always be upgraded, but wine is not preinstalled.
At the same time, we understand that wine is important for many people, and that’s why it got documented among Ask Fedora > Common Issues . There’s not much more we can do. It now depends on the package maintainers, and or any volunteers who can look into the issue and try to come up with a solution (it seems to be a hard packaging problem). Fedora is a community distribution, so it all depends on whether the right people are available and willing to help. A number of packages are maintained by paid Red Hat employees (not wine, though) and the Quality team has also employees, but all our time is mostly spent on ensuring the the system get actually get installed and booted into desktop, and that the OS basics work.
Thanks for you feedback, though, we hear it and are trying to come up with processes that improve things. (Like at least documenting, if not fixing, high-profile issues).
Unfortunately, in discussion forums you’ll get a lot of bad advice, even if people mean it well. That’s why we separate the official documentation of the issue in Ask Fedora > Common Issues, which has a solution which we verified and trust it (as much as we can), and the user discussion, where you can get more advice, but also might not work.
Regarding wine, let me just append a personal tip - Steam doesn’t need system wine (it contains it already), and for non-Steam games and apps, install Bottles from Flathub. It’s a Flatpak, which means you get more security through sandboxing, and as a Flatpak it’s again separated from the host system, so all wine installations are again standalone in it, which means you don’t need system wine at all. Plus Bottles has a very nice UI.
1 Like
Here’s an update that claims to fix the upgrade problems. Testing is very welcome:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-4a2922869f
Please note that updates-testing repo needs to be enabled during the upgrade so this can be picked up. It might also take a day until it’s visible in that repo.
1 Like
This is now fully resolved. Just the wine-core issue was resolved. See:
1 Like
Caveat: It may still fail on some systems, like it did on mine. In which case, the previously established workaround of removing the main wine package should be employed, as it’s likely due to a limitation of dnf itself.
I posted about it in another thread, but this was the error message I still got:
Problem 1: wine-dxvk-2.6.2-1.fc42.i686 from @System has inferior architecture
- wine-dxvk-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
- problem with installed package
Problem 2: wine-dxvk-d3d10-2.6.2-1.fc42.i686 from @System has inferior architecture
- wine-dxvk-d3d10-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
- problem with installed package
Problem 3: wine-dxvk-d3d8-2.6.2-1.fc42.i686 from @System has inferior architecture
- wine-dxvk-d3d8-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
- problem with installed package
Problem 4: wine-dxvk-d3d9-2.6.2-1.fc42.i686 from @System has inferior architecture
- wine-dxvk-d3d9-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
- problem with installed package
Problem 5: wine-dxvk-dxgi-2.6.2-1.fc42.i686 from @System has inferior architecture
- wine-dxvk-dxgi-2.6.2-1.fc42.x86_64 does not belong to a distupgrade repository
- problem with installed package
I don’t think aksing the packagers to continue spending time debugging what’s now a niche issue is of any benefit, so if you’re still getting the error, just do the manual workaround.
I updated the issue description again, mentioning that just the wine-core problem is fixed, not wine-dxvk one.