Wine development version

[Eonfge]

I know what I'm asking... it's a monstrous job to package every development release of Wine, but i do think that it's question that must be asked.

The point why I bring this up, is because applications like Q4Wine that rely on the Flathub-provided wine version, are now not really viable. Especially in the past three or so years, where the development of wine has accelerated, not having access to wine-development is a serious downside.

[gasinvein]

Previous discussion in the matrix channel reached consensus that packaging every Wine version isn't practical.

Packaging a "rolling" always-latest development and/or staging branches could make sense, but Q4Wine and other frontends won't be able to easily switch between Wine branches, or provide the user a way to change them. So, if we have to pick one Wine flavour, stable branch seems a reasonable default.

To be clear, I'm not against packaging other flavours, but I'd like to have concrete use-case scenarios for them first.

[Erick555]

For flexibility, the current approach would need to be changed from baseapp to extensions, something I proposed in flathub/flathub#2845 (comment) .

[Eonfge]

Fair, let's not do extra until there is a good use case. Perhaps applications like Q4Wine should follow the path of Lutris and Bottles, and download wine runtimes themselves.

@Erick555 In the quote following, Bartłomiej makes the rightful comment that there is only one @gasinvein and that we should not exceed the resources that we as volunteers can put together. I wholeheartedly agree with that statement, but it might be worth pinning this issue and listing it as a known limitation and/or help-wanted issue.

[gasinvein]

Kinda off-topic, but...

Q4Wine should follow the path of Lutris and Bottles, and download wine runtimes themselves

Oh, I hope not. I prefer Q4Wine over the other Wine GUIs for the very it's free from random prebuilt binaries.

[Erick555]

Note that downloading prebuild wine runtime from winehq doesn't ensure its ABI compatibility with flatpak runtime.

As for the maintenance cost - extension that contain only wine could be fully automated. Actual cost would be the initial manifest (and design) preparation. Something like this would need to be pre-accepted by flathub in order to prevent someone from wasting their time.

[sjenkins7]

Stumbled across this a while back while trying to experiment with a building a Flatpak that requires the current wine-staging ( the current version simply doesn't work ).

I'd be open to jump in and help out supporting this going forward, if more hands are needed ( once the discussion with Flathub has been had of course ).

[eszlari]

To be clear, I'm not against packaging other flavours, but I'd like to have concrete use-case scenarios for them first.

The obvious use-case: Being able to test new Wine development releases easily cross-distro, so one can report bugs/regressions upstream. Best case scenario would be, if the Flatpak was listed as an official way to test Wine at:

https://wiki.winehq.org/Download

Packaging a "rolling" always-latest development and/or staging branches could make sense

Yes, and also: Flatpak already brings its own tools for roll-back: flatpak update --commit=COMMIT

[JamiKettunen]

I'm currently using this flatpak via Bottles for a game and it so works much better than any of the available binaries for download via Bottles (since all of them are currently 7.x or older releases)!

I'd love to check out https://www.winehq.org/announce/8.3 which just released since it contains another potentially interesting fix for an issue I've been having (Wine heap performs badly when multiple threads are concurrently allocating or freeing memory)

Update: a newer version definitely made it work perfectly now (no multi-second freezes during certain actions) and I've been using https://github.com/Kron4ek/Wine-Builds/releases via Bottles this whole time, so this stable version provided became useless for me a long while back until 2024's next update

[user1-github]

I actually hope this Flatpak will stay on stable Wine versions. I need Wine for a few Windows apps which all work perfectly on wine-stable. So I don't need to use Wine managers like Lutris or Bottles which use custom patched Wine versions (that are pretty much always based on Wine devel versions). I can directly double click the app exe or create my custom .desktop shortcut to it.

I don't want to use wine-devel versions because they are pre-release versions (just like pre-release versions of any other software), which means more bugs and regressions. And they're really less stable from my experience.

Also, this Flatpak is extremely useful for conveniently getting wine-stable on most distros these days (on immutable distros it's pretty much the only way to get wine-stable). I don't know any distros other than Debian and Ubuntu that ship wine-stable in their repositories these days. All the other distros ship wine-devel.

I know there is also a wine-stable Appimage, but some apps don't work on it and Appimages generally don't work on some distros like OpenSUSE Aeon.

[gasinvein]

The stable branch isn't going anywhere for sure. This feature request is about adding a different Wine branch to Flathub, not replacing the existing one.

[user1-github]

The stable branch isn't going anywhere for sure. This feature request is about adding a different Wine branch to Flathub, not replacing the existing one.

Yeah, I just wanted to say that wine-stable is useful for some people like me. Many people lately seem to think that wine-stable is pretty much useless and that everyone these days is using wine-devel or some custom patched version from Lutris/Bottles.