Add wine base app

[ermshiperete]

No description provided.

[Erick555]

This version is outdated. use 18.08

[TingPing]

I'm not sure we want this here:

• Typically very specific wine versions are used with specific applications for best compatibility
• BaseApps on Flathub are for apps on Flathub
  • I don't believe we want WINE apps on Flathub since they are unsupportable, will never be native (use portals), and are always unofficial

[Erick555]

I would prefer plain wine flatpak or flatpak for wine wrapper like q4wine or POL.

[Saroufim]

Perhaps the best solution would be to revive winepak or come up with a similar solution.

[ermshiperete]

I thought a base pack is for splitting an app into separately updatable packs.

BaseApps on Flathub are for apps on Flathub

This is a base pack for a specific app - see PR #798. Would it be better to rename this base pack to com.tntware.tntconnect.BaseApp?

[TingPing]

Would it be better to rename this base pack to com.tntware.tntconnect.BaseApp?

That makes even less sense, the entire point of baseapps is to share build time.

[LeandroStanger]

@ermshiperete Use the Proton

[scx]

I agree that this is not a very good idea.

@Erick555

I would prefer plain wine flatpak or flatpak for wine wrapper like q4wine or POL.

plata (POL developer) said:

This will not happen for PoL/PoM4. However, we might do so for the upcoming Phoenicis PoL/PoM 5.

https://www.playonlinux.com/en/topic-15675.html#m61438

However, we have a Steam client that features SteamPlay/Proton.

See also:
#191

[Erick555]

Flatpak for Phoenicis is already done but they won't submit it to flathub until Phoenicis itself leave the alfa stage.

Using wine is much more than games (BTW: claims that you need some ancient wine versions to play them is a weird myth). I wouldn't want to wait till someone package calc.exe as flatpak. I would prefer to jut run flatpak run org.winehq.wine calc.exe myself, the same way as I do with wine installed natively.

[TingPing]

The Lutris developer is interested in Flatpak but there is no ETA at all about that.

[scx]

@Erick555

Using wine is much more than games

PlayOnLinux is not only for games.

BTW: claims that you need some ancient wine versions to play them is a weird myth

Regressions in WINE are a fact. That's why software like PlayOnLinux exists.

I wouldn't want to wait till someone package calc.exe as flatpak. I would prefer to jut run flatpak run org.winehq.wine calc.exe myself, the same way as I do with wine installed natively.

As @TingPing said:

Typically very specific wine versions are used with specific applications for best compatibility

This is not just about the version. Additional components (Microsoft Visual C++ Redistributable packages, codecs, fonts, DLLs, etc.) and settings (virtual desktop, CSMT, audio backend, Windows version, etc.) are very important too. Almost every major application should have its own virtual disk and registry.
If you try to run everything on only one prefix, you will quickly spoil it.

What's more, Flatpak is indented to run GUI apps, so pure WINE is not very suitable here.

When it comes to WINE-based applications (bundled Win32 apps), I believe that snapcraft is a better place for them. They are already there.
Example: https://snapcraft.io/notepad-plus-plus

However, I wouldn't mind if TntConnect also appeared here.

[TingPing]

When it comes to WINE-based applications (bundled Win32 apps), I believe that snapcraft is a better place for them. They are already there.

To be clear this isn't a technical difference, but one of policy where anything can be dumped on their store (because it has to be since there is only one store).

[Erick555]

Regressions in WINE are a fact. That's why software like PlayOnLinux exists.

Regression fixes are a fact too. In oftware like PlayOnLinux apps are kept with ancient wine versions because nobody touched their profile for the last 5 years.

This is not just about the version. Additional components (Microsoft Visual C++ Redistributable packages, codecs, fonts, DLLs, etc.) and settings (virtual desktop, CSMT, audio backend, Windows version, etc.) are very important too. Almost every major application should have its own virtual disk and registry.
If you try to run everything on only one prefix, you will quickly spoil it.

You don't need flatpak to use wine prefixes.

[scx]

@Erick555

Regression fixes are a fact too. In oftware like PlayOnLinux apps are kept with ancient wine versions because nobody touched their profile for the last 5 years.

Sometimes it is true. Sometimes, however, you need a specific version of WINE to run the selected program/game (see common WINE postfixes in POL: *-staging, *-CMST, -*rawinput*, *-LeagueOfLegends*).

You don't need flatpak to use wine prefixes.

I didn't say anything like that. My point is that to get the best compatibility, you need to choose the right WINE version with the specified parameters and additional components. Then such a Flatpak/Snap bundle can make sense.
To just get latest WINE you can use PPA/OBS/COPR repo or download it via PlayOnLinux.

[Erick555]

I didn't say anything like that

Then whole text I quoted was completely irrelevant to this discussion.

To just get latest WINE you can use PPA/OBS/COPR repo or download it via PlayOnLinux.

I have latest wine in my distro default repos already. Flatpak has other benefits though.

[barthalion]

I don't think there is anything to add to what @TingPing has already said. We denied such requests in past and nothing has changed since then.

Flatpak doesn't enforce a single store like Snap does, so it's perfectly possible to host separate repository, like it was the case with Winepak.

[barthalion]

I'm not necessarily against the base app itself though, however I'm afraid it will not receive enough attention to be kept up to date for multiple release branches.

[scx]

@barthalion

I'm not necessarily against the base app itself though, however I'm afraid it will not receive enough attention to be kept up to date for multiple release branches.

What is the point to have the BaseApp for WINE, when no app on Flathub will be able to use it? Even if it was allowed, how do you want to solve the problem that one application requires WINE in such version and the other one requires another variant? Do you suggest creating a branch for every possible version? I mean, we do not even have nodejs in Electron BaseApp, due to possible (but rather unlikely) compatibility problems.

[barthalion]

I already said how I want to solve it. The point of doing so is simple – there was idea in past to share build infrastructure with Winepak, we can very well just host the base apps ourselves.

I mean, we do not even have nodejs in Electron BaseApp, due to possible compatibility problems.

I don't think you really know why it is so. Electron base apps were meant for repackaging binary releases, not builds from source code.

[scx]

@barthalion

I already said how I want to solve it. The point of doing so is simple – there was idea in past to share build infrastructure with Winepak, we can very well just host the base apps ourselves.

As far as I know, they don't use their own BaseApp but the whole runtime - org.winepak.Sdk/org.winepak.Platform.
Moreover, it is based on Freedesktop 1.6, and as you said before, you no longer accept software based on this runtime. But of course, the rules are fluid, so you do whatever you want. :)

I don't think you really know why it is so. Electron base apps were meant for repackaging binary releases, not builds from source code.

Just like here? :)
https://github.com/flathub/chat.rocket.RocketChat/blob/1aee77e9b84be46ce5467b9856368cf9bb70b2a1/chat.rocket.RocketChat.json#L145-L146
https://github.com/flathub/com.bitwarden.desktop/blob/16ecfae90dffb072ca5d2ea3900cb34bf0a8c961/com.bitwarden.desktop.yaml#L57-L58

I am afraid that this is impossible without npm from the nodejs package.

See also:
http://docs.flatpak.org/en/latest/electron.html#building-node-js
https://github.com/flatpak/flatpak-docs/blob/f3705c200250c11783041c3ec3ccf7f70d49694d/docs/electron.rst#building-nodejs
https://github.com/flathub/electron-sample-app/blob/21797dad234841cb17bdd2148fb48b1a1d5d5f77/flatpak/org.flathub.electron-sample-app.json#L26-L42

[LeandroStanger]

winepak/winepak-sdk#12

[scx]

@barthalion

More examples:
https://github.com/flathub/chat.rocket.RocketChat/blob/1aee77e9b84be46ce5467b9856368cf9bb70b2a1/chat.rocket.RocketChat.json#L29-L45
https://github.com/flathub/com.bitwarden.desktop/blob/16ecfae90dffb072ca5d2ea3900cb34bf0a8c961/com.bitwarden.desktop.yaml#L21-L33
https://github.com/flathub/com.endlessm.HatchPreviewer/blob/c8cdbb9c7e603b2c9c3338a5975499259baae656/com.endlessm.HatchPreviewer.json#L26-L42
https://github.com/flathub/com.jgraph.drawio.desktop/blob/61085c178ea8b463d965b437e8597f928d5ea623/com.jgraph.drawio.desktop.yml#L21-L33
https://github.com/flathub/com.sublimetext.three.DevUtils/blob/6bc85fdea9668f2563bceecb85920a0889dcd1b6/com.sublimetext.three.DevUtils.yaml#L49-L61
https://github.com/flathub/electron-sample-app/blob/21797dad234841cb17bdd2148fb48b1a1d5d5f77/flatpak/org.flathub.electron-sample-app.json#L26-L42
https://github.com/flathub/id.sideka.App/blob/dfd7544f84e470858d3dac73687faf87c6058470/id.sideka.App.json#L26-L42
https://github.com/flathub/io.github.betaflight.BetaflightConfigurator/blob/62c8ea8794d296e2c386b7792f88bb7e97c80d44/io.github.betaflight.BetaflightConfigurator.json#L41-L57
https://github.com/flathub/nz.scuttlebutt.Patchwork/blob/556746068b7e016cd9d1bb9e7bbf770ed094973c/nz.scuttlebutt.Patchwork.json#L31-L47

It is clear to me that we are wasting time building nodejs on our own.

[LeandroStanger]

@ramcq Had a conversation with @winepak https://twitter.com/ramcq/status/1028206450995286016

[barthalion]

As far as I know, they don't use their own BaseApp but the whole runtime - org.winepak.Sdk/org.winepak.Platform.

Sure, because it makes more sense, which makes this PR even more moot if WInepak is going to be a thing again.

But of course, the rules are fluid, so you do whatever you want. :)

I think we all will appreciate if you finally quit trolling.

Just like here? :)

I know you like to show off your grep skills but it doesn't change the original intent. If it also deduplicates work for source-based builds, better for us.

[Erick555]

I think Winepak is pretty much dead currently.

[julianrichen]

In regards of winepak, finding time to work on it has been my biggest issue. I have been working on the infrastructure and I do have an Ansible playbook to setup a better environment with buildbot. The buildbot-config has been giving me some issues. Haven't wanted to publish anything until it works right but I might just dump everything so other can help.

Getting a working buildbot up and running is probably the best thing for winepak so others can push changes and update the repo. Right now every commit has to be approved, built, and pushed by me. Buildbot would automate that and allow other approved contributors to help.

Would anyone on Flathub be able to help finish-up the buildbot-config?

[ramcq]

@julienrichen It feels very odd to me that we can't figure out a way to support Wine runtimes directly on Flathub infrastructure. It's a great candidate to deliver and demonstrate benefits of Flatpak providing a stable execution environment, and a useful tool for onboarding ISVs who have Windows software to port.

Flathub-ists? What if we just add it to builds.json and off we go? We have other emulators, other downloaders, other not-third-party-blessed things, no?

[TingPing]

I have nothing against sharing build infrastructure I just didn't want the store to be filled with windows software.

[barthalion]

Indeed, virtually unsupportable Windows software is the problem, not Wine itself,

[julianrichen]

@ramcq Sharing infrastructure would be even better, I would rather have someone more competent than me maintaining that aspect. I know we talked on Twitter about setting-up multiple repos. I believe you mentioned Flathub was interested in having a free & non-free software repo?

I also agree with @TingPing @barthalion that wine software should be split off from Flathub. It could hurt Flathub's image since someone might download a currently working game and the devs of that game might make a change that wine doesn't handle yet. Now Flathub has broken software. It's even worst since we cannot compile the actual Windows software and see if it breaks before pushing :/ This is as oppose to users adding dl.winepak.org with the explicit understanding that stuff can become broken.

I would be more than willing to point dl.winepak.org to a different winepak specific Flathub repo and even pay for a dedicate server for winepak builds. My other concerns is the amount usage we might consume. Most winepak apps are quick to build since they are just init scripts and a third-party downloader. One of the main goals of hosting a buildbot instance was to have the last 3 ~ 4 wine-staging SDKs rebuilding weekly with older versions being rebuild occasionally, mainly for security reasons to keep-up with changes in the fd.o SDK. Currently wine-staging has 22 releases, so for winepak that's 22 versions... on-top of the normal 3.0 & 4.0 release. Building SDKs can take a while and from my understanding most SDKs on Flathub are imported from the freedesktop, gnome, and kde repo right? The dedicate server for winepak should solve most of those issues but not sure what kind of changes would need to be made on Flathub's side to accommodate.

Does Flathub have a repo just for infrastructure talk? Might be better to move this discussion to another thread.

[LeandroStanger]

@julianrichen Create an account at Patreon for winepak

[julianrichen]

@ramcq Has there been any internal discussion about multiple repos?

[muelli]

Suggested change

	branch: 4.0
	branch: "4.0"

[Eonfge]

I would prefer plain wine flatpak or flatpak for wine wrapper like q4wine or POL.

Has been requested:
brezerk/q4wine#147