[feat] Bundle Tauri apps as Flatpak

Question

[feat] Bundle Tauri apps as Flatpak

puyoxyz opened this issue 3 years ago · 30 comments

puyoxyz commented 3 years ago

Describe the problem

According to this page, Tauri apps can only be bundled as .deb or AppImage.

Describe the solution you'd like

An option to bundle Tauri apps as Flatpaks.

Alternatives considered

No response

Additional context

No response

Answer 1 · 2022-03-05T20:54:56.000Z

fwiw, flatpak and rpm support is on my todo list, but i won't start working on it until after v1 stable is released (if nobody beats me to it by then)

Answer 2 · 2022-06-16T18:01:29.000Z

Hi! I'm interested in taking a stab at this.

There's two ways this could be accomplished:

Generating installable Flatpak single-file bundles (similar to APKs on Android.)
Creating a Flatpak manifest that can be used with flatpak-builder to build an app into a repo or uploaded to Flathub for distribution.

The first requires the second, but is ultimately easier to accomplish as the build process could access the internet (Flathub disallows internet access during builds on their runners). The first is also more in line with how the other bundlers work.

In my WIP, I've named the first method flatpak in BundleTarget in tauri.conf.json. Would it be better to call this flatpak-bundle to allow for the second method in the future or is the second way not really a goal?

Answer 3 · 2022-06-16T19:26:10.000Z

Great to hear you're interested in working on it!

With method 1, is there then any way of publishing to flathub or similar? I would imagine that's what most people would be looking for in a flatpak target.

Answer 4 · 2022-06-16T19:44:18.000Z

AFAIK, you can't publish a Flatpak bundle directly to Flathub, you have to submit a manifest. However, I think the best course of action is to:

Create a Flatpak manifest that can create the Flatpak without network access (declaring the crates and other dependencies as sources), then
building the app and exporting a bundle.

This gives the user a bundle that they can host themselves and a manifest that could be submitted to Flathub with minimal changes (likely just changing where the app's sources are downloaded from).

This has a slight downside in that the app will have to be compiled twice (once on the host for the other bundlers, and once in the sandbox by flatpak-builder, but ultimately I think this is a good thing since the app will be built in the same environment that it will run in, and the generated manifest contains everything necessary to build the Flatpak on it's own.)

There could also be an option to disable generating the Flatpak bundle and only generate the manifest, skipping the building phase and preventing compilation from happening twice.

Answer 5 · 2022-06-16T22:23:01.000Z

Happy to report that I made quite a bit of progress towards this!

It's definitely still a work in progress, but for now it can:

Generate a Flatpak manifest that can build the app without network access
Build and export the app as a .flatpak bundle

From here, I think it needs to be made a bit more reliable, and will definitely need documentation added.

Should I open a draft PR?

Answer 6 · 2022-06-17T06:53:55.000Z

With method 1, is there then any way of publishing to flathub or similar? I would imagine that's what most people would be looking for in a flatpak target.

Yep, that's a really important part of flatpak, [in my opinion] adding just flatpak single-file bundles isn't enough

Answer 7 · 2022-06-21T13:50:42.000Z

@owendaprile beat me to it there 😄
That said I've not built flatpaks before so glad you're looking into it. Let me see where I can help out.
This is the branch you're working in right? https://github.com/owendaprile/tauri/tree/feat/bundler/flatpak

Answer 8 · 2022-06-21T14:58:32.000Z

@Beanow Yeah, that's where I'm working from. I haven't been able to work on it in the past few days, but I can explain my strategy. Currently, it compiles and installs the app inside the sandbox, which overall is better since it means the library versions on the host don't matter and there won't be any dependency issues (unlike the AppImage, where the host library versions matter). However, this is a lot more difficult because flatpak-builder disables network access during the build process, and all sources need to be declared in the manifest. I was having trouble copying sidecar binaries in and getting the correct path to install them. After thinking about it, I think there's only really two paths forward for building the Flatpak:

Building the Debian package on the host, specifying that as the source in the manifest, then extracting the data archive and copying all those files to /app. This is the easiest method, but means there can be library incompatibilities depending on which distro builds the Debian package.
Specifying the entire project tree as the source for the Flatpak, installing cargo-tauri as a build dependency, use that to build only the Debian package (or make another bundle target that generates a tarball and use that) and extract those files and copy them to /app. This avoids the library compatibilities. (However, now that I think about it, this would require the app to have the source code public if submitted to Flathub.)

In either case, some extra settings will have to be added to the bundle settings for specifying extra permissions past the required ones.

When I have more time, I'll join the Discord and try to figure out which path is best and what other requirements there are.

Answer 9 · 2022-06-21T16:01:53.000Z

@owendaprile I've been poking around and trying your branch, and that approach is what I wonder about as well.
I'm still learning about flatpak though so I don't know how people tend to approach this yet. Consider my comments mainly questions as I look into it 😄

Currently, as you mentioned for the AppImage, the "host" already needs to be a controlled environment (we do this with Github Actions) when making releases. And both the Deb and AppImage are created by compiling on the 'host', then the bundler copies build artifacts, assets and libraries as needed.

This is similar to what you would do with a multi-stage docker image.

FROM some-image as builder
...

FROM scratch
COPY --from=builder ...

Where GH Actions handle this "builder" stage, and "copy from builder" is what the bundler does for you.

While I can see where you're coming from wanting to build inside the target sandbox, the issue I see is build dependencies for people's Tauri projects may vary wildly. And now you'd end up maintaining two parallel build environments. The one for flatpak builds and the existing build environment / GH actions.

I think if we're going to depend on / unpack the deb package, we'd essentially be leaning on the existing approach. Wouldn't it make more sense to generate a manifest which sources directly from the compiled src-tauri/target/release/...?

Answer 10 · 2022-06-21T17:00:24.000Z

If it's already expected that the bundler is running in a controlled environment, then I think it's okay to build on the host and copy all the required files into the sandbox.

I still think it's better to use the deb package (or some equivalent archive) because that's just one archive that can be pointed to as a source for all the applications files. Reducing the number of sources listed in the manifest is better because when submitting the manifest to Flathub, all the sources have to be publicly available for their builders to download. (Flathub doesn't allow you to upload a Flatpak bundle, only a manifest). The AppImage bundler also starts from the deb package as a base. This would also reduce code duplication as only one bundler (the debian one) does all the real work and the other just work from that as a base.

I think it's important for the generated manifest to be as easy as possible to modify for submission to Flathub, as that's where most people will want to distribute their Flatpaks.

Maybe we could ask some Flathub reviewers/maintainers what would be the best approach for easy submission?

Answer 11 · 2022-06-21T17:17:06.000Z

Flathub doesn't allow you to upload a Flatpak bundle, only a manifest

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 😅

And I agree, not having a Flathub option is a no-go in my opinion.

Maybe we could ask some Flathub reviewers/maintainers what would be the best approach for easy submission?

In the long run, I think that makes sense. For several reasons, such as if we could save people hassle and bandwidth with a runtime/base app, like they use for Electron https://docs.flatpak.org/en/latest/dependencies.html#base-apps.

For the moment though, I feel like I just need to do the homework xD
There's a good amount of reference manifests on https://github.com/flathub
Plus the docs at https://github.com/flathub/flathub/wiki/App-Requirements
I'll spend some time on that, see where it gets me.

Answer 12 · 2022-06-21T17:39:55.000Z

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.

Answer 13 · 2022-06-21T17:46:20.000Z

@owendaprile I opened #4426, let's brainstorm there to limit notifications for others here.

Answer 14 · 2022-10-27T11:58:21.000Z

This is flatpak's cargo template/script: https://github.com/flatpak/flatpak-builder-tools/tree/master/cargo
I feel like there should be a cargo-flatpak or something already but there's none.
We could probably provide such tool in the end. Or if anyone is interested, this could be an excellent opportunity for side project.

Answer 15 · 2022-12-03T22:00:42.000Z

https://github.com/flathub/in.cinny.Cinny is an example of an app using tauri that's Flatpak'ed, and I'm working on packaging the above referenced pocket-sync.

Answer 16 · 2022-12-03T23:00:14.000Z

https://github.com/flathub/in.cinny.Cinny is an example of an app using tauri that's Flatpak'ed, and I'm working on packaging the above referenced pocket-sync.

pocket-sync review for Flathub: flathub/flathub#3688

Answer 17 · 2022-12-04T00:35:38.000Z

Looks really good @hadess!
I've not had time to work on it, but I know it comes up with the team regularly as something we still want to do.

In #4426 I got to the point where I could tauri build a .flatpak single file while using networking locally or in GitHub Actions. With the idea being, to use the build artifacts as input for FlatHub manifests. Because not all applications built with Tauri are necessarily Open Source, so rather than compiling on FlatHub with offline packages, it would extract pre-compiled assets.

Either way, if you're able to help think about good approaches, or with implementation that would be great 🙏

I'm sure @wusyong and @FabianLars have thought about it more, since my last work on it too.

Answer 18 · 2022-12-04T08:59:41.000Z

In #4426 I got to the point where I could tauri build a .flatpak single file while using networking locally or in GitHub Actions. With the idea being, to use the build artifacts as input for FlatHub manifests. Because not all applications built with Tauri are necessarily Open Source, so rather than compiling on FlatHub with offline packages, it would extract pre-compiled assets.

The fact that I'm using Flathub is completely tangential to the fact that, by default, flatpaks require offlines sources. Requiring offline sources means that apps are reproducible, which is important even for proprietary apps, to limit unwanted changes, whether for sources "bill of materials", following the terms of software licenses, or just making it easier to debug something!

You can obviously build your apps locally, or on a private servers for Flatpak, just like you were able to compile debs and RPMs targets for your apps.

Doing online builds, whether it's for Flatpak, debs or appimages, doesn't give you any way to check what sources were actually used, and verify them, to make sure they didn't have a particular bug, or backdoor. Rebuilding the app with the same sources might give you a different result.

But that's not any different to the other binary target you currently have. Just make sure that the "right" way with offline source generators is mentioned.

Answer 19 · 2023-10-29T20:17:42.000Z

any update?

Answer 20 · 2023-12-10T11:43:10.000Z

Would like support for this please! Flatpak is my favourite package manager ;)

Answer 21 · 2023-12-10T12:21:52.000Z

any update?

Answer 22 · 2023-12-13T20:56:08.000Z

I added support for arch and rpm via github actions

https://github.com/don-cryptus/clippy/blob/master/.github/workflows/release.yml

Answer 23 · 2023-12-13T22:21:02.000Z

I added support for arch and rpm via github actions

https://github.com/don-cryptus/clippy/blob/master/.github/workflows/release.yml

any progress for debian?

Answer 24 · 2023-12-13T22:22:40.000Z

I added support for arch and rpm via github actions
https://github.com/don-cryptus/clippy/blob/master/.github/workflows/release.yml

any progress for debian?

tauri already bundles .deb thats how I am creating the arch and rpm packages

Answer 25 · 2023-12-13T23:28:12.000Z

I added support for arch and rpm via github actions
https://github.com/don-cryptus/clippy/blob/master/.github/workflows/release.yml

any progress for debian?

tauri already bundles .deb thats how I am creating the arch and rpm packages

so after this will this issue be resolved?

Answer 26 · 2024-07-28T20:16:23.000Z

I'd like to share my learnings around converting a v1 tuari app from AppImage to flatpak.

I could not get the AppImage to run, it would segfault, see repro. Instead I had to use a the .deb build but I don't really know if there are implications to that as I'm not a linux user.

https://github.com/Hacksore/flatpak-tauri/tree/appimage

Answer 27 · 2024-07-29T10:15:03.000Z

At Axolotl we just build the Flatpak with cargo.
You can find the manifest here and the cargo invocation here.

It would be great if we could just cargo tauri build for Flatpak as we do for deb and appimage already.

Answer 28 · 2024-08-20T10:04:03.000Z

any update?

Answer 29 · 2024-08-20T10:43:15.000Z

We recently started working on docs here https://v2.tauri.app/distribute/flatpak/ (v2 only because v1 requires building webkitgtk from scratch - if you're interested in that, just search for tauri in the flathub github org). It currently only shows a manifest that relies on an existing .deb build. In the future we'd like to have one using the sources directly similar to the comment above #3619 (comment) (contributions are always welcome).

Direct flatpak support in tauri build isn't much of a prio right now, even though (or because) we want to push flathub as the primary distribution format on Linux.

Answer 30 · 2024-08-20T13:29:11.000Z

can this issue be pinned here