feat: Flatpak support #75
Comments
|
This sounds like a really good idea, then all major Linux distros can simply get one package from one remote, be up to date and functional |
|
I do think Flatpak is a thing that'd benefit Viper, however As for the SteamDeck we still have to actually solve #38, which I plan on doing soon. Beyond that I have no clue how Viper will work on the SteamDeck considering the screen size and the fact that Viper currently doesn't allow for user resizable windows, even if I've tried to keep the UI mostly responsive between updates and simply disabled resizing, I'm not sure which parts aren't actually responsive in actuality. Not to mention how we'd auto-fullscreen or whatever we may need to do when it is launched, I don't have a SteamDeck reserved, and likely won't have one any time soon, so if somebody does in fact have one when they become available it'd be amazing if said person could test Viper on it.
Absolutely not, AppImage at the very least will remain a format, as I know many people who have a grudge against Flatpaks, but I also know many who have it against AppImages etc, since they handle sandboxing and alike differently. Also there's a major difference in app sizes, which deter some users from using Flatpaks and staying with AppImages. There's many reasons to hate both formats, and the reasons above are the reason I much prefer AppImages, but I still wanna point out how I'm completely on board with still adding it as a format, as I see where it's useful. |
|
So looking at currently release material around steamdeck, flathub seems to be the source for flatpaks on steamdeck and flatpaks are installed via Discover and can be added as non-Steam games. Bonus: Apparently Steamdeck runs Titanfall 2 quite well: https://twitter.com/killyourfm/status/1498385708100292608 |
That issue is still annoying to solve, as there's no easy way to detect what Wine/Proton version to run with or its settings etc... Or just in general whether to even run it through that, overall, Linux launch support by itself is easy, making it work automatically and OOTB is not. The biggest issue with Flatpak support is how we build it, as I've stated before, I've no clue how to do that, however if someone figures that out feel free to comment on it here... When I get the time I'll try researching it myself, but I can't give an ETA on that. |
Last time I investigated this, I found a bunch of resources that might be of use to speed up researching ^^
|
|
Alternatively to building from source we could probably just pull the AppImage and place it inside the Flatpak runtime, similar to how popular proprietary apps on Flatpak do it. Examples here and here. Once that is setup we can then try to figure out how to do it "properly" later :P Only issue with the AppImage, is that we need to had some logic to make sure it has self-updating features disabled as that stuff should be handled by Flatpak. |
Hm, there's likely some changes to the filesystem for Flatpaks that we can detect, unless it doesn't sandbox it like that? That or we can just have a build script that makes a file which when present will disable the auto update, then it'll remove it after the Flatpak is built?
If we can get all that to work, considering everything, there's not much reason to do it "properly", if it works it works, and there won't be a difference on the users end... (I Think?) |
One could probably detect or set (at build time) some at build time that indicates to the AppImage that it is being run inside a Flatpak environment. Personally I'd go for disabling the update check at build time by making a second AppImage target called |
Perhaps there's a way to get the name of the AppImage file? Then we simply check for that, and disable auto updates accordingly...
We can just add it to the |
|
Apparently However I haven't managed to get it running inside the electron-builder Docker container: Maybe you have more success when building natively / outside of Docker environment? ;) |
I got the same error, realized by "spawn" it means execute, i.e the command I'll try and see what I can do after fixing the Flatpak Steam issue... |
Seems like simply putting the AppImage inside a Flatpak container is not an option (due to AppImage using FUSE and such) but "converting" them should be an option according to this reddit thread. |
|
Searching for Flathub released Flatpaks I found one that unpacks an AppImages and uses only a small manifest. I modified it a bit and managed to build and run Viper with it :D app-id: com.github.OneGal.viper
base: org.electronjs.Electron2.BaseApp
base-version: '20.08'
runtime: org.freedesktop.Platform
runtime-version: '20.08'
sdk: org.freedesktop.Sdk
command: viper-run
separate-locales: false
tags: []
finish-args:
- --socket=x11
- --share=ipc
- --share=network
- --device=dri
- --filesystem=host
modules:
- name: unappimage
buildsystem: simple
build-commands:
- make -C squashfs-tools -j ${FLATPAK_BUILDER_N_JOBS} install INSTALL_DIR=/app/bin
sources:
- type: git
url: https://github.com/refi64/unappimage
commit: d7f86f2a0d7ec3a69211125207d5f127386b849a
- name: viper
buildsystem: simple
build-commands:
- unappimage Viper-1.2.5.AppImage
- rm Viper-1.2.5.AppImage
- mv squashfs-root /app/bin/viper
- install -D viper-run -t /app/bin
sources:
- type: script
dest-filename: viper-run
commands:
- zypak-wrapper /app/bin/viper/viper "$@"
- type: file
filename: Viper-1.2.5.AppImage
url: https://github.com/0neGal/viper/releases/download/v1.2.5/Viper-1.2.5.AppImage
sha256: 21e1c2f456c7318256fb8bd15d229e50f8392f372c99c6bf3fd89bb5524c73f6
size: 103176664 |
|
Aight, I pushed up the proof-of-concept Flatpak that just takes the AppImage and unpacks it inside the Flatpak environment. I still need to check permissions, Of course, optimal version would be to just use |
|
Aight looks like can now consistently build a Flatpak version from the AppImage. Currently this pulls the AppImage from the Github release page so not really helpful for adding it as a target on github release but perfect for releasing on Flathub :P We probably wanna look into adding it a package there soon: https://github.com/flathub/flathub/blob/master/CONTRIBUTING.md Also before you say anything, the reason the package id is |
Any way to add variables or similar as to not change the same number multiple places just to update the version?
That seems rather dumb, and like a useless limitation. |
Not that I'm aware of. My solution would have been a small Bash or Python script that just regex replaces the version numbers and updates file hash and size. Commit that and push it to the repo under Flathub org and flathub-bot takes care of building and publishing. Would have to do that on any new Viper release of course but once things are set up we probably wanna look into automating that any way. Regarding the package id, is |
|
Also while within Flatpak environment the auto-update part of the AppImage fails somehow anyway and therefore prevents updates other than Flatpak, I think it would probably make sense to add a |
In what way does it fail? Does it spit anything out on in the logs?
Agreed. |
Honestly, I'm not quite sure... Starting viper after a clean build of Additionally, trying to run it with |
From what I know: |
|
So I can link it in the application PR, can you publicly confirm that I'm allowed to redistribute Viper via Flathub? ^^ |
I confirm :) |
|
Submission for Flathub has been accepted :D The created repo can be found here: https://github.com/flathub/com.github._0negal.Viper Once published (there's a default 3 hour delay between build and publish on Flathub), it can be found here: https://flathub.org/apps/details/com.github._0negal.Viper |
What feature would you like added?
I'd like to propose Flatpak as an additional distribution format.
Why should this feature be added?
Flatpak is rising to become the defacto standard for distributing up-to-date end-user-facing graphical applications (usually referred to as "apps" by end users). It's distro agnostic thanks to isolation features and runtimes, and it features built-in auto-update by the Flatpak environment (so a user doesn't need to open Viper to update it).
Further Flatpaks will be supported out of the box on Steam Deck so with a Flatpak release future Steam Deck users could install Viper without needing to enter any form of developer mode on their device.
Additional Info
There are some drawbacks with adding a Flatpak version. In particular I'm not sure if we can deprecate other Linux formats in favour of Flatpak as even with widespread support on major distros some users might not have Flatpak installed in their repo by default. Most prominent example being Ubuntu (all its derivates support it out of the box). This means we'll have to support yet another distribution format.
(This feature request was created out of a discussion in the Northstar Discord)
The text was updated successfully, but these errors were encountered: