Project information:
Wine (originally an acronym for “Wine Is Not an Emulator”) is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
Wine is pretty complex software and could be packaged in few different ways. Users and maintainers requested it for a long time from 2017 but never communicated loudly enough and all this turns in fragmented threads, polemics, debates, WineBaseApp proposals which was denied many times by Flathub admins and as the result is that there almost 2021 but we still doesn’t have Wine (and it derivatives) on Flathub. Also upstream never was even notified and no one even tried to communicate with upstream and ask to package Wine.
This is META thread for all Wine packaging related aspects on Flathub. The ultimate goal is to have Wine (and it derivatives) as standalone package and as reusable Wine build for 3rd party FOSS launchers such as Lutris, Legendary, q4wine, PoL, Legendary and such.
The oxymoron is that working Wine flatpak build was made for a long time by couple community members and flatpak manifest available in their repositories. It’s proven to work well and tested for decent period of time by group of people. This mean nothing is prevent to publish Wine right today if upstream don’t mind and not wait for decades approval of controversial proposals like WineBaseApp. Or if upstream will want to maintain it then this going to be perfect.
I really like this idea! It would bem lovely to have, similarly to as we are have in snaps, wine applications on flathub (such as Python IDLE for windows which I use regularly to compile some python code).
But afaik, flathub doesn’t support 32bit binaries, so what’s the plan ? Use only 64bit wine?
It feels like it would be useful to have both a Wine package and a Wine runtime+SDK.
The Wine package would allow to easily test/run Windows apps with different releases of Wine (which would be a nice improvement compared to distribution packages).
The Wine runtime+SDK would allow to package Windows apps entirely and make it rather transparent to the end-users. Examples: game launchers (mostly Windows-only), small apps like LunarMagic (to create Super Mario World romhacks), etc, etc.
I’ve done this here, but it’s not what I would default to.
If not for Flatpak limitations, I would go with an SDK extension and a Platform extension for every Wine major release, and for one for unstable releases.
The limitations that I’m referring to are:
Inability to package the Platform extension when building the SDK extension, similar to how we build runtimes. This issue also forcing us install Java runtime from the SDK extension into /app and bundle it with the app instead of having a Platform Java extension that can be mounted on a mount target from the runtime.
During apply_extra, extensions of any kind are not mounted, so no app extension, nor runtime extensions, and I want to create a Wine prefix and install an app during apply_extra.
Maybe you should consider building something together.
I’m sure Julian would be happy if you contact him and offer help or to maintain Winepak from now on.
