#Flatpak build guide?

1 messages · Page 1 of 1 (latest)

sharp plank
#

The page about distribution on linux specifies that there are six ways to distribute on linux, including flatpak, but flatpak is the only one for which there is not a guide listed. I recall seeing a guide on the tauri website about half a year or a year ago for distributing on flatpak but somehow I cannot seem to find it back, does it no longer exist?

8hVR8gp.png
sterile lantern
cerulean river
sterile lantern
#

nothing planned on our side. i never really saw much value in these types of flatpak bundles and rarely ever see them in the wild. And well, you can quite easily create them yourself with basically the same config you use for flathub.

cerulean river
#

That's true. I dont think the process is hard.
But I use the github releases and the latest.json that tauri-action spits out quite heavily (for app updates and download links for instance),
so I have to shoehorn the generated flatpak into both the github release and the json file manually, which will be a bit of a pain

#

In terms of value, I see it in a similar fashion as AppImage, it's a single file bundle you can distribute to any distro, except unlike AppImages, you can actually install them without 3rd party tools (and not just run them).
I'm building a closed source app right now and with Linux distribution, I dont know yet what I should do. AUR is out of the question if my github repo is private. AppImage is the best I have so far (I do think updates are supported? Havent tested that yet).

With flatpak published to flathub, the user gets update through that. If I build bundles myself, I'm on my own here too, unless the updater (and thus tauri-action) actually bundle and release it that way 🤔

#

But well, that's another topic. I just feel a bit lost, and I'm not sure if my usecase is covered in any way (outside of AppImage)

#

Would definitely vastly prefer Flatpak single file bundles over AppImages, given that it sounded like the latter are painful and/or even deprecated

sharp plank
#

I actually have pretty much the same situation lol, not exactly at a point where I'm looking to do auto-updates yet, but I also feel like it's a bit more customary for things distributed via flatpak or AUR not to auto-update but leave that up to the user

sterile lantern
#

the updater plugin does not, and very very likely will not support flatpak, neither repository dists nor single-file bundles. At least the updating/installing part, checking for updates is easy.
For repository distributions the reason should be obvious, for single-file bundles it's a) why should we when we don't support the bundles directly and b) is it even possible? there are like 0 resources on this topic so it's hard to tell. I would also expect the flatpak format to have "protections" against this in place.

#

given that it sounded like the latter are painful and/or even deprecated
flatpaks and appimages are both painful in their own ways. As much as i'd love to, appimages aren't deprecated in tauri either, i'm just working on a replacement for the current bundler.

sterile lantern
cerulean river
#

Since last time I figured out that you can host your own flatpak repo on github pages,
which should (even for closed-source projects) allow users to just add the repo and install my app (+ keep it up to date).

I'm trying to integrate that into my tauri build pipeline now. Since we can build and export .deb, I'll just have the flatpak manifest download the newest deb file and install it (as per your example), and export that as a flatpak repo to github pages

#

If that works, I think it's a vastly more appealing way than having non updatable flatpak bundles

cerulean river
#

Well except github pages isn't free for private repos, so I'll just push the flatpak repo files to my s3 bucket, ez

cerulean river
#

I wrote a flatpak manifest that downloads the newest .deb build of the app, and I'm actually getting to install it, but when running the app it always crashes with

thread 'main' (2) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libappindicator-sys-0.9.0/src/lib.rs:41:5:
Failed to load ayatana-appindicator3 or appindicator3 dynamic library
libayatana-appindicator3.so.1: cannot open shared object file: No such file or directory
libappindicator3.so.1: cannot open shared object file: No such file or directory
libayatana-appindicator3.so: cannot open shared object file: No such file or directory
libappindicator3.so: cannot open shared object file: No such file or directory
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#

I assume that is because the library has a different name under Arch based systems

sterile lantern
#

no that .so is part of the flatpak runtime so the host distro shouldn't matter

#

you need to add a module to the manifest for appindicator though, not sure if that was part of the guide

cerulean river
#

don't think it was.
Would you mind pointing me into the right direction on that one?

sterile lantern
#

try to find out how to use that as it has the libayatana-appindicator module you need

cerulean river
#

yup that fixed it, thank you!

#

it's running now. Probably need to figure out how to fix deep links and stuff but that should be minor nuisances

cerulean river
#

Its weird that, despite the .desktop file clearly having the deep link scheme mime type defined, KDE just doesn't pick up on it.

sharp plank