Hi! I maintain a Proton/Wine extension that is often used as an add-on for Steam, and there is interest from my users in releasing it as a Flatpak to make installation (much) easier for that use case.
The issue is, the build process requires Wine and a mingw32(64) toolchain. Currently I have it building on GitHub Actions (with the relevant Ubuntu packages). Distributing the prebuilt binaries in Flatpak would be easiest, but I understand that’s frowned upon.
What’s the best/allowed way to approach this? I think getting the build to work inside flatpak-builder is probably doable if pulling in a prebuilt Wine as a build-time dependency is acceptable. I see there’s an sdk extension for MinGW, but not Wine itself (Wine itself is a Flatpak though). I don’t really want to maintain a Wine SDK extension just for this, I don’t have the bandwidth for that.
Pulling pre-built wine to build the package instead of pulling pre-built package seems like fancy for the sake of wasting CI minutes.
Well, on Flathub it is an requirement to build the software from source, whenever possible:
As I understand it, you need Wine only to link against it during build? During runtime it would use whatever Wine is used by the game, as set in Steam?
Yup that is the how it is supposed to work.
Yes, headers and linking. I think the only code from wine that ends up (statically) in the final executable is probably winecrt0 (startup code)?
Is it acceptable to build the wine from source, use it as build dependency and then remove it in cleanup?
I think that would be fine, though building all of Wine just for this seems… less than ideal…
Now, I can’t give an definitive answer. That would have to come from an official Flathub team member during the review of an actual manifest.
I’m just a guy who makes comments in different places.
But I can see the argument that building Wine from source just so it can be used to link against it during the build of the actual software, could fall under the “maintainability concerns” part mentioned in the requirements.
Make sure though that anything else can be build from source, the Wine being pulled is from an official source and you can provide the argument up-front about this.
1 Like
Yes, everything else is being built from source (including a forked libpipewire built statically to work around an ancient version in steamrt3). The rest of the dependencies should be stuff that’s in the SDKs.
(There are technically some blobs in one of the git submodules becase upstream’s repo is kind of messy with their example projects, but it’s just junk, not used during the build. I assume that’s not a problem.)