Page MenuHomeSolus

Suggestion: wine-staging
Closed, WontfixPublic


Hi there,

I'm well aware it's been declined in the past to add a wine-staging or to provide wine-staging at all. Now, it's not the first time wine isn't supporting certain games anymore, but we have major titles being impacted (LoL, WoW 9.x or in general Blizzard games with the updated engine etc.), and it's a question of time until they provide the patches in upstream wine (probably). Since wine 5.15 there has not been any progress on those issues, all works good enough in staging though.

The question I want to ask is if it wouldn't be better to provide a wine-staging with the distribution besides wine for people who choose to run it if wine falls short of patches. It's actively preventing players to run their games within the distribution unless they get the PoL wine-staging 5.19 and start their games with that version. We'll run in those issues again and again, since wine is very traditional about patches (which is a good thing for stability, that has to be said), but the game devs seem to get ahead more quickly.

May be a bit much of an effort for a temporary solution for players until wine gets patched up, just wanted to gather your opinion on this. It usually takes quite a while until -staging patches are merged to the master of wine, so players may be locked without those games for weeks and month.

What's the dev teams thought about this? Rather go without supporting those titles for the moment until wine gets patched up and wine-staging not an uption, or is a seperate wine-staging an option? As I said, PoL is an option (Lutris is not, their wine is way too outdated).

Just wanted to gauge the opinion on that again. Players usually default back to the system-wine if something is not working, and in those cases, wine stable does not do the job. At least not anymore at the moment.

Event Timeline

STiAT created this task.Oct 17 2020, 9:29 PM

I still believe that wine development is the best compromise between wine stable which is way too conservative and slow to update and wine staging which often break things that were previously working. Having a wine that can randomly break and fix things every month isn't something we want.

As you said, you can use play on linux for such things, can't you ?

As far as I know Lutris picks up PlayOnLinux Wine versions if installed. For the ease of use, I'd use that.

Jacek added a subscriber: Jacek.Oct 18 2020, 4:07 PM

And if we want a wine version that has best possible game compatibility, why not Proton-GE T9232? Although in its default configuration it does not replace system-wide wine, so it is not quite what you are asking for, but game compatibility is miles better than wine-staging.

PooLee added a subscriber: PooLee.EditedOct 18 2020, 4:20 PM

I would suggest asking community who is using Wine for what. At this point I belive native apps are enough for most of the things. And if they're not (like CAD) - Wine won't provide stable experience anyway. Doesn't matter if -staging, -devel or stable.

With the statement above my perception of situation looks like this:

wine ---> wine-development ---> wine-staging
unstable ---> more unstable ---> propably even more unstable

And we pick middle one as it's "unstable enough"...
It's funny, cause this compromise feels like "worst of the both worlds".

It's 2020, except games people aren't really using Wine anymore for Office work or anything like this.

Plus, why does the team care so much about Wine having this one version? There are another apps that have 2 packages in repo like for example Vivaldi or kernel.

Wine always was one of the most important software in Linux world. It needs a special treatment. It's not the first time people ask about it. I recall this discussion happens more times than discussion about other DEs like XFCE or Cinnamon.

JoshStrobl closed this task as Wontfix.Oct 18 2020, 5:15 PM
JoshStrobl added a subscriber: JoshStrobl.

WINE in Solus is primarily made available for win32 application (not game) compatibility and it predates gaming-oriented compatibility and translation layers / software such as DXVK and Proton. It's been on the development branches for a long time now, for the reasons @kyrios123 elaborated to above, which I'll also quote:

wine development is the best compromise between wine stable which is way too conservative and slow to update and wine staging which often break things that were previously working. Having a wine that can randomly break and fix things every month isn't something we want.

I am not interested in shipping WINE Staging, whether that's using it as a secondary source to apply on top of WINE, or standalone. The only reason we even have wine-nine-standalone as a separate package is because it moved to being standalone, presented value at the time, and does not conflict with WINE. In fact, it literally uses our WINE. Shipping wine-staging as an alternative to WINE is not an option because we have a very clear policy on not having multiple ABI providers whenever it's possible, and for places where we could have multiple providers, they're not allowed to conflict (see OpenJDK 8 vs 11, libnm-legacy vs NetworkManager, etc.). Adding it as a secondary source during build-time only introduces the potential for greater amounts of instability and compromising the intended usecase of WINE under Solus.

If you need WINE / DXVK / Proton for gaming, you can always use Lutris. If a specific app is "lagging behind" in Lutris, you always have the option to work with that Lutris install script developer to validate and update it against a newer version of DXVK, Proton, specific version of WINE, etc. That is consistent with my reasons for rejection of DXVK per T8504. In the case of very specific games like World of Warcraft, these issues are typically resolved fairly quickly. It's fairly understandable that it wasn't compatible (may not be yet, I only play it under Windows) given Blizzard dropped the ball on the pre-patch release dates and pushing back Shadowlands to an unknown date. I doubt people were actively testing it against the PTS and beta builds. I've dealt with the same thing when it came to updates to Elder Scrolls Online, like the Greymoor DLC release.

And regardless, I'm not going to have is compromise the stability of a larger system over a potential short-term benefit that can be resolved through other means.

Regarding the kernels and something like Vivaldi, those are completely different. One is the kernel and offering linux-lts provides significant value given not all hardware plays nice with linux-current. Vivaldi is something I maintain and I file issues with the Vivaldi team via testing against the snapshot. It doesn't conflict at all with stable, they're co-installable.

STiAT added a comment.Oct 23 2020, 9:24 PM

Fair enough, thank you for the clarification Josh.