Approach to creating Flatpak bundles

[Beanow]

Moving discussion from #3619 to brainstorm about how we should build/publish Flatpaks.

[Beanow]

#3619 (comment)

Well that puts us into a chicken-or-egg problem. None of the build artifacts would be published on a public URL known to the bundler at that time. Because it's in the middle of the job of creating them sweat_smile

Yeah, we can't make a manifest that works without modification on Flathub, but we can make one that is as simple as possible to modify for submission to Flathub. I think the right strategy is to generate a manifest that references the deb somewhere on the local filesystem, so the Flatpak can be built locally. The docs should then advise users to host the deb package and adjust the manifest to point towards that URL when hosting on Flathub.

The local manifest would look something like this:

"sources": [
    {
        "type": "archive",
        "path": "tauri-app.deb"
    }
],

and you'd only have to change it to this for submission to Flathub:

"sources": [
    {
        "type": "archive",
        "url": "https://example.com/dl/tauri-app.deb",
        "sha256": "..."
    }
],

I don't think a base app is necessary because the GNOME platform has the required dependencies already (GTK 3 and webkit2gtk) and as far as I know that's all that's required for a Tauri app to run. I guess webkit2gtk and some other dependencies could be put in a base app but that's much more maintenance effort than just using the GNOME platform.

[Beanow]

@owendaprile so I got a version working that build by extracting the .deb.
Beanow@fc629f9

But discussing with @FabianLars I ran into a downside to this approach. For .deb and .appimage you MUST build in an environment that has the oldest glibc (and webkit2gtk) you want to support. So if that's like ubuntu1604 for you, that's the webkit release you're going to get as well.

Flatpak in theory wouldn't have this limitation, the org.gnome.Platform / org.gnome.Sdk runtimes have pretty up to date glibc and webkit2gtk included. But by extracting a LTS-style .deb we wouldn't take advantage of it.

---

So here's an alternative idea I'd like to experiment with. What if we do compile our things inside org.gnome.Sdk. But use full networking. Extract a flatpak-artifacts.tar.gz from it and publish that (alongside your bin, .deb, .appimage, .flatpak) and target this for the flathub modified manifest? This way we could avoid offline building issues, and target a modern webkit2gtk version in flatpak.

See also #3961

[owendaprile]

I like this strategy. It removes any library version mismatches too. Would we do this every time you run cargo tauri build (even though that would compile the project twice)?

The only thing I'm not sure about is how to get artifacts out of flatpak-builder. The build directory might have them, and we can just copy them from there, or we could run a shell flatpak-builder --run and get the artifacts from stdout. The implementation on the Flatpak side is pretty easy, you only have to add this to your manifest:

"build-options": {
    "build-args": [
        "--share=network"
    ]
},

I'm trying this out right now to see what is possible.

[Beanow]

Would we do this every time you run cargo tauri build (even though that would compile the project twice)?

Yes, at least if you've got bundling activated. But that's a good thing:tm: because targeting different environments is a valid reason to build again. I've got this 90% working at the moment. Just need to figure out some finishing touches and it should compile 🤞

[owendaprile]

Also, does Tauri allow you to change the src-tauri/ directory to something else? I currently reference that in the manifest and if it can be changed, there would need to be some way to find it instead of hardcoding it.

[Beanow]

Sure does 😂
Hence I forwarded this to handlebars
https://github.com/Beanow/tauri/blob/fc629f9f132b8eafebde938c7aba6afab8dba748/tooling/bundler/src/bundle/linux/flatpak.rs#L91

[Beanow]

Making some good progress on the local build to produce the single file .flatpak flavor.

• Got parameters for many paths, and which tauri command/version to use.
• Added fixes for system tray icons to work.
• Got the Github Action to build, cache and publish artifacts.

Still in my own forks though, though the first PRs are in the making.

I've got a little demo app here: https://github.com/Beanow/hi-flatpak
Including GH action published releases.

[ljrk0]

Hi all, I'm currently trying to package https://elk.zone as Flatpak so maybe I can share some insights on the preferred workflow for that.

Already Flatpak'ed Tauri Apps

FWIW, some people already successfully packaged Tauri apps:

• https://github.com/flathub/in.cinny.Cinny/blob/master/in.cinny.Cinny.yml
• https://github.com/flathub/io.github.neil_morrison44.pocket-sync

Flatpak Manifests vs. Flatpak Bundles

Generally, though, publishing a Flatpak usually does not mean to provide a downloaded .flatpak (a so-called bundle) but to provide a recipe that allows for (reproducible?) builds of said file. This recipe comes in form of a YAML or JSON manifest to be fed into flatpak-builder. It, plus some metadata, is the only thing that's supposed to be uploaded to a service such as flathub.org. The build workers should be able to simply run flatpak-builder on the manifest.

While being able to use cargo create-tauri-flatpak or similar to build a .flatpak file is definitely a neat thing, this doesn't integrate with said workflow.

Creating Manifests

• Implement something such as cargo create-tauri-flatpak-manifest which collects the manifest, as well as the generated-sources.json(s) for pre-downloading/vendoring all sources and other data
• Do something like create-tauri-flatpak but make it simply run flatpak-builer on said files.

References

Additionally, it'd be also interesting on how GNOME Builder does that. From what I can gather (e.g., from here), it simply

• Creates the Flatpak manifest on project creation (I'm not sure whether it automatically updates it if needed) which is then checked in into version control.

I'm not sure which way is easier to implement though.

Blockers / Problems

While packaging elk.zone I discovered in cooperation with @JonasKruckenberg that currently we have the dependency chain [email protected] => [email protected] => [email protected] which in turn makes use of javascriptcore-rs in version 0.16 which internally then uses javascript-core-rs-sys 0.5.0. Unfortunately that links against javascriptcoregtk-4.0 which is deprecated for a while already and not available in the GNOME 43 SDK but only in 42 and before.

Unfortunately these work only with the Rust SDK from 21.08 which ships a too old cargo to work with Rusts workspaces feature. I have to investigate whether the above mentioned Flatpaks workaround this or simply use an older Tauri version that doesn't make use of workspaces.

[FabianLars]

For your blocker/problems section. You could try tauri's next git branch where we upgraded webkitgtk. we can't ship that to a 1.x release because a) the gtk crate had a huge msrv version bump that we can't yet follow (we will change our msrv approach in v2), and more importantly b) it's a huge bump in the min supported Linux version (for the lack of a better term).

[ljrk0]

We'll try, Jonas is currently tracking #6174 and Hubert is trying to fix flathub/org.freedesktop.Sdk.Extension.rust-stable#209 in order to bring Rust 21.08 up to speed.

Meanwhile, I found out why Cinny and Pocket Sync probably, they don't use tauri-plugin-store which makes use of some of the more complicated Rust workspace features:

• https://github.com/neil-morrison44/pocket-sync/blob/v2.3.0/src-tauri/Cargo.toml#L31
• https://github.com/cinnyapp/cinny-desktop/blob/v2.2.4/src-tauri/Cargo.toml#L20

FWIW, there's also a related issue with Cargo, vendored dependencies and the Workspaces feature: rust-lang/cargo#11192

[hadess]

While packaging elk.zone I discovered in cooperation with @JonasKruckenberg that currently we have the dependency chain [email protected] => [email protected] => [email protected] which in turn makes use of javascriptcore-rs in version 0.16 which internally then uses javascript-core-rs-sys 0.5.0. Unfortunately that links against javascriptcoregtk-4.0 which is deprecated for a while already and not available in the GNOME 43 SDK but only in 42 and before.

Unfortunately these work only with the Rust SDK from 21.08 which ships a too old cargo to work with Rusts workspaces feature. I have to investigate whether the above mentioned Flatpaks workaround this or simply use an older Tauri version that doesn't make use of workspaces.

FWIW, the GNOME 42 SDK is not supported anymore:

Info: runtime org.gnome.Platform branch 42 is end-of-life, with reason:
   The GNOME 42 runtime is no longer supported as of March 21, 2023. Please ask your application developer to migrate to a supported platform.

So it would be great for Tauri to support newer WebkitGTK so we could use supported runtimes, which would also bring newer versions of Rust for application developers to use (see flathub/io.github.neil_morrison44.pocket-sync#54).

Should I file a separate issue about this?

[FabianLars]

tauri v2 already upgraded to a newer webkitgtk version (4.1). We of course can not change it in 1.x.
Also, there are a few flathub tauri projects now building webkitgtk in the flathub action itself, of course that increases build time by an hour or so but you can keep using tauri v1 at least.

[qu1ck]

@FabianLars any links to such apps and/or their flathub recipes? I don't mind long build times if they are on a github action anyway.
Also it seems like a BaseApp would solve the webkitgtk build time issue, similar to how there is electron BaseApp. Has anyone looked into that?

[FabianLars]

We know about the BaseApp approach but didn't really look into how well it would work for us because v2 is relatively close to a release (still a few months!) and will update webkitgtk versions. Also we don't really have resources to allocate on that (especially if it fixes itself in v2 and if there are 2 workarounds for v1).

One of the first flathub tauri apps i heard about was this https://github.com/flathub/in.cinny.Cinny/ iirc they also came up with building webkitgtk themselves.
But if you search in the flathub org there seem to be quite a few more: https://github.com/search?q=org%3Aflathub%20tauri&type=code - there should be even more than that because if you base it on the .deb installer there doesn't have to be any mention of tauri in the repo whatsoever.

If those repos don't help you i can try to find some more when i'm back from EuroRust :)

[robertosw]

Hi there :D
I've struggled my way through understanding flatpaks in the last days and I'd like to help. I've read everything here and in the original issue, but still don't know whats blocking the progress currently. Could someone summarize that please?

---

I really like this idea: #4426 (reply in thread). As far as I know, GitHub Actions are just like docker containers, right?
I found a docker image for the freedesktopsdk runtime but couldn't find one for the gnome runtime. Maybe we can create one based on the freedesktop runtime?

I tried building a flatpak for my simple tauri app based on this freedesktop runtime, with this .deb approach. Building and installing works, but this currently fails at runtime because there is a hardcoded path to webkitgtk that I cant link to the correct path. So the gnome runtime would probably be the better pick for this case.

My idea would be to require the developers to build their .deb in the container image of the gnome runtime, and use this .deb package to build a flatpak with the same runtime.

• Is there anything stopping this?
• I don't know a lot about flatpaks single-file bundles, so I dont know how this approach translates for these. But this would allow any program (closed and open source) to be published to Flathub. The manifest references a .deb package, extracts its contents and possibly installs additional libraries, which could be published next to the .deb file

[robertosw]

Experiments here: https://github.com/robertosw/tauri-flatpak-tests

[robertosw]

I just tried my idea (building in the docker container of freedesktopsdk). The docker container is basically a pure linux kernel. This would be quite painful to setup, so I'll be discarding that idea :D

[robertosw]

tauri v2 and gnome//45 work together perfectly. I suppose you already knew that? But why was it not written anywhere?
I'll try to get something working for tauri v1 if that's wanted. I myself would benefit from it.

[FabianLars]

This is all a bit over the place, sorry in advance:

but still don't know whats blocking the progress currently. Could someone summarize that please?

For v1 the missing webkitgtk dependency in the non-deprecated runtimes but v2 is close enough that we shouldn't bother imo.

For v2 nothing really. imo it could be solved by just adding docs for it since it's simple enough (if using the .deb as a base). We could add a flathub config generator to the cli/bundler but that's also only useful for the first time publishing the app. After that you'll have to edit it manually yourself anyway (not that we couldn't automate anything here but it's not worth it imho).
So for v2 the real blocker here was that i mostly gave up on linux (still managing community prs, just not actively working on stuff myself) and nobody else seemed to care about it. Also, the v2 docs were in flux which made adding docs for it weird too.^1

I tried building a flatpak for my simple tauri app based on this freedesktop runtime, with this .deb approach. Building and installing works, but this currently fails at runtime because there is a hardcoded path to webkitgtk that I cant link to the correct path. So the gnome runtime would probably be the better pick for this case.

Hmm, i thought building the .deb on the ubuntu runner would just work ™️ because of flatpak being able to hook into it somehow but that already doesn't work in appimages (which also has the same problem but there we can patch the path in the built binary which probably doesn't work for flatpaks)

My idea would be to require the developers to build their .deb in the container image of the gnome runtime, and use this .deb package to build a flatpak with the same runtime.

I assume you're talking about closed-source software? Because open source could build in flathub directly somewhat easily.

I don't know a lot about flatpaks single-file bundles, so I dont know how this approach translates for these.

tbh, nobody actually cares about them, the only usecase that comes to mind is sharing dev builds with friends or whatever. appimages could serve as an alternative, and building it manually is pretty easy too. But yeah, for actually distributing flatpaks these are useless so shouldn't be a prio for us at all imo.

tauri v2 and gnome//45 work together perfectly. I suppose you already knew that?

Yep

But why was it not written anywhere?

🤷 (also, see above ^1)

I'll try to get something working for tauri v1 if that's wanted. I myself would benefit from it.

for tauri v1 check out my comment above #4426 (reply in thread) - cinny is the example i typically mention for this. But yeah, that should not be added to Tauri v1 itself in any form, requiring v2 for flatpaks is fine.

[robertosw]

Alright 👌 if there is help needed for linux and especially flatpaks (in v2) I'd love to help.

[robertosw]

I opened a pull request which adds a docs page for this: tauri-apps/tauri-docs#1760