FEAT: Publish Linux version as flatpak

[rugk]

Is your feature request related to a problem? Please describe.
A simple and easy way to install applications on Linux, which alos work cross-distro in a good way.

Describe the solution you'd like
It would be nice if you could publish this as a flatpak on flathub e.g.

Flatpaks are a new software distribution mechanism for Linux distros, can thus installed on any distro and are easy to update. Thy are easy to install and work on all Linux distros.
Also, if you publish it on FlatHub you may grow your user base given many distros include that and it is a common software source, so your app can be discovered more easily.

Here is how to get started.

Describe alternatives you've considered
There is also “snap“, but I would highly advise against using it.

I personally would prefer flatpak. Because in contrast to snap, you can also self-host it, so you stay in control, and it is widely supported. (snap is not so nice to setup in many distros and snap's security depends on AppArmor, which is not always available in many distros)
Also – in contrast to snaps – flatpaks do not only claim to be distro-independent, but actually aren and they are widely adopted.
Furthermore even Linux Mint criticizes snap, because you cannot self-host a snap server as it is proprietary and (thus) also cannot modify the packages that are served centralized by Ubuntu.

[joaolucasgtr]

Totally agree with this.

Also, snaps takes forever to startup, which is annoying too!

[markovic-nikola]

+1

Currently, I'm using DbGate through the AUR, but the version is outdated (v5.0.6).

[asjur]

Is there an update on this? We have snap, but not flatpak. 😬

[ProjectInfinity]

@janproch Any chance for either creating a flapak bundle or publishing on flathub?

Snaps really isn't widely supported and are potentially dangerous to use outside of Ubuntu.

Edit:
Since dbgate uses electron-builder, flatpak support is simple.
https://www.electron.build/configuration/flatpak.html

I managed to get it to build, install and run.
What I did was:

1. Change package.json to include flatpak in the list of linux targets.
2. Set env variable when building. env DEBUG="@malept/flatpak-bundler" yarn run build:app
3. Run flatpak install on the missing 20.08 runtimes.
4. Change appid to org.dbgate.DbGate (as flatpaks require 2 periods in their name)

[janproch]

@ProjectInfinity Thank you for trying it. I am working on it now

[janproch]

flathub integration PR flathub/flathub#3955

[ProjectInfinity]

How is this going? What's the blockers?

[janproch]

The biggest problem is that fork() function doesn't work correctly when distributed as flatpak

[rugk]

Another tip as this uses Electron AFAIK: Many Electron apps (based on the Chromium engine) use Zypak for sub-sandboxing. I did not yet fully understand how it works, but maybe linking flathub/com.vscodium.codium#55 may help and you can see the links/linked implementation there.

[rugk]

The biggest problem is that fork() function doesn't work correctly when distributed as flatpak

I have no idea of Electron development and only a grasp of flatpak development, but I've tried to ask ChatGPT about that (before summary if you want to continue). It basically recommend other strategies for offloading work (IPC or so) or when asked regarding Electron it suggests Web Workers specifically e.g.

Summary by ChatGPT

Certainly, here's a summarized overview of the proposed solutions to handle the fork() issue in Electron-based applications within a Flatpak context:

1. IPC Mechanisms: Utilize Electron's IPC mechanisms to enable communication between the main process and renderer processes. This allows for parallelism and task distribution without relying on direct process forking.

2. Background Processes and Workers: Leverage background renderer processes and Web Workers to handle tasks that would have been suited for separate child processes created with fork().

3. Process Offloading: Distribute tasks across existing processes using well-defined communication patterns instead of creating separate processes with fork().

4. Architectural Adaptation: Design your application's processes and communication channels to be compatible with sandboxed environments, aligning with the constraints of platforms like Flatpak.

5. Web Technologies: Leverage modern web technologies like Web Workers, asynchronous programming, and event-driven architectures to handle background tasks and maintain application responsiveness.

6. Task Delegation and Management: Manage tasks by delegating them to appropriate components or modules, using asynchronous patterns, and coordinating tasks without relying heavily on traditional process-based concurrency.

By adopting these approaches, you can effectively work within the sandboxed environment of Flatpak while avoiding the use of the fork() function in your Electron-based application.

[ProjectInfinity]

The big issue I am finding is that the subprocesses seem to die, and I am not quite sure why. Maybe it is related to Zypak but I do not know enough about it to confirm.

[rugk]

/cc @refi64 I took the liberty to CC you here, as for a potential problem of Zypak. I hope this is okay.

Otherwise, @ProjectInfinity, maybe ask on https://github.com/refi64/zypak/issues if you think it is about Zypak or otherwise maybe ask the flatpak/Flathub community?

[refi64]

Unfortunately I can't try this out myself, because Electron versions <18.3.2 don't work on my system due to lack of support for 16k kernels. That being said, is there anything interesting logged? If not, does setting ZYPAK_DEBUG=1 show anything?

[ProjectInfinity]

Unfortunately I can't try this out myself, because Electron versions <18.3.2 don't work on my system due to lack of support for 16k kernels. That being said, is there anything interesting logged? If not, does setting ZYPAK_DEBUG=1 show anything?

Hi, sorry for the slow response it's been quite busy. Attached you will find the log file when running the built flatpak using ZYPAK_DEBUG=1. Unfortunately, I am not familiar enough with zypak to immediately tell you if there is an obvious problem with the log.

zypak.log

[janproch]

Second attempt to publish to flathub repo: flathub/flathub#5240

Subprocess die issue seems to be fixed with upgrading electron

[ProjectInfinity]

Second attempt to publish to flathub repo: flathub/flathub#5240

Subprocess die issue seems to be fixed with upgrading electron

I can attest to the issues I experienced being fixed, so far it seems to work just like the AppImage.

Great that electron update fixed it because debugging zypak was not simple. 👍

[janproch]

Flatpak version published on flathub: https://flathub.org/apps/org.dbgate.DbGate

[rugk]

Awesome! A download button on https://dbgate.org/ would be great, too.

[ProjectInfinity]

Awesome! A download button on https://dbgate.org/ would be great, too.

Already is!