FR: Wine package on Flathub

Questions about Wine on Linux
Locked
Tim4
Newbie
Newbie
Posts: 2
Joined: Wed Dec 23, 2020 4:31 am

FR: Wine package on Flathub

Post by Tim4 »

Hello.

I've found similar old topic which was stale and locked automatically but since old request doesn't receive any attention or didn't noticed i would like to ask again to provide official Wine package on Flathub.

From end user perspective having official, well maintained and widely tested universal Wine package huge win and very desirable thing and have few strong points. It's also have strong points from devs/maintainers perspective.

Having official Wine on Flathub for end users and devs mean:
  • Safe and trusted build.
  • Well maintained, always up to date and widely tested Wine package. Wine devs know better how to package their own app.
  • Official Wine bug tracker always open for end users who using this package and build.
  • Users can safely switching between different Wine branches, such as Stable, Devel, Staging. Usually only one version provided by Linux distribution, only wine-staging in Fedora for example. And adding 3rd party repos not always the best choice and have their own drawbacks. Also users often reporting bugs which not reproduced in official build but producing in build provided by distribution and vice versa. All this confusing and users and just increase debug cost and time.
  • Collabora devs recently talking on FOSDEM about importance of isolating Wine apps from the host system. Flatpak can help a lot with this. Valve working now on their own tool and runtime for Proton which pursuit the same goal.
  • Others 3rd party FOSS launchers, like Lutris, Legendary, q4wine, PoL, Legendary and such, could reuse same Wine package and not reinvent the wheel every time. This also mean CrossOver could be packaged as well and reused the same, battle tested Wine build. Win-win.
  • Reducing maintenance burden in many times.
There was already few attempts and requests packaging Wine on Flathub from 2017 but this was not communicated loudly enough and Flathub about upstream and app devs in first place, not about 3rd party maintainers. This gives full control to upstream on their own software and no middleman. There still many thing which requires discussing first and polemics how Wine should be packaged but community always can help there and there already exist fully working Wine community builds which i've tested thoroughly and it's proven to work very well. 🚀

🔗 https://flathub.org
🔗 https://github.com/flathub/flathub/wiki/App-Submission
Bethel49
Newbie
Newbie
Posts: 1
Joined: Wed Dec 23, 2020 3:57 pm

Re: FR: Wine package on Flathub

Post by Bethel49 »

Thx for this proposal, I hope it gets some attention. Few questions below:
Users can safely switching between different Wine branches, such as Stable, Devel, Staging
Do you mean having all of those in single flatpak or having one wine branch per appid?. IIRC you cannot use different flatpak app branches at the same time.
Others 3rd party FOSS launchers, like Lutris, Legendary, q4wine, PoL, Legendary and such, could reuse same Wine package and not reinvent the wheel every time.
IIRC flatpak app can't interact with other flatpak apps other than through portals due to sandboxing. How 3rd party launcher is expected to use this official wine app then?
Tim4
Newbie
Newbie
Posts: 2
Joined: Wed Dec 23, 2020 4:31 am

Re: FR: Wine package on Flathub

Post by Tim4 »

Bethel49 wrote: Wed Dec 23, 2020 4:06 pm Thx for this proposal, I hope it gets some attention. Few questions below:
Users can safely switching between different Wine branches, such as Stable, Devel, Staging
Do you mean having all of those in single flatpak or having one wine branch per appid?. IIRC you cannot use different flatpak app branches at the same time.
Probably this is most important part and need to decide and discuss in first place how Wine should be packaged:

- Standalone application (flavors on different branches) — app/org.winehq.Wine//staging
The current status quo. It can be based on, but there can be only one base, which means that there will be no choice of taste — only the current baseapp.

- Single extension (flavors on different branches) — runtime/org.flathub.WineExt//staging
Eeasy to reuse and can replace one flavor for another without rebuilding, but only one can be used at a time.

- Extension with subdirectories (flavors with different ID's) — runtime/org.flathub.WineExt.Staging//stable
Easy to reuse any number of any flavors in any application, but you cannot bind add-ons for a Wine (gecko/mono/dxvk/etc) to its branch.

But TBH any of this still better then we have current approach in Linux distros with classic package managers.
Others 3rd party FOSS launchers, like Lutris, Legendary, q4wine, PoL, Legendary and such, could reuse same Wine package and not reinvent the wheel every time.
IIRC flatpak app can't interact with other flatpak apps other than through portals due to sandboxing. How 3rd party launcher is expected to use this official wine app then?
Trivial if Wine would packaged as runtime or as extension. Also possible if as baseapp. Here is very, very dirty example where standalone Wine build used in 3rd party launcher.
Locked