Limit Linux app distribution methods to AppImage and flatpak

[developomp]

Description

Is your feature request related to a problem? Please describe.

Currently, the anytype desktop client is distributed to Linux in three formats (https://download.anytype.io): AppImage, deb, and snap.

• deb
  • is a format specific to debian-based distributions (e.g. ubuntu and pop-os).
  • the anytype team has to rely on random people repackaging the app for different distros. Creationg many different points of failure.
• snaps
  • flatpak is a far more favored option in the Linux community.
  • Can't build for ARM64 on AMD64 (#83)

Describe the solution you'd like

I suggest only building AppImage targetting amd64 and arm64 then making them also available as flatpaks on flathub. This can be done by using flathub/flatpak-external-data-checker. Here is an example of it working in action.

This drastically simplifies the building, testing, debugging, and maintaining process for the Linux platform.

[rzelnik]

Disclaimer: I am not an Anytype developer or team member and everything I write here is just my private opinion.

Limiting installation formats is a good idea in general. Distribution-specific package formats like deb or snap should be maintained by creators of the distributions instead. This however is not the case for Anytype yet. It is not known enough, distribution creators didn't add it to their repositories yet and users don't request it to be added there. You can not install Anytype desktop in the usual way from the app stores (not even from Snapcraft), so the only way is to download it and install (deb|AppImage|snap) manually. This makes it difficult for users to maintain up-to-date versions, because AppImage is the only format that is able to update a manually installed application (I am not sure if it works for Anytype). In addition, as I recently learned here, update checks only work with AppImage.

I support adding flatpak as a widely accepted distro-agnostic package format, but removing any existing format in this situation would make installation of Anytype in the fragmented Linux world even worse. If it is possible to maintain installation packages automatically, the more the better. Rather ask our distribution creators to add Anytype to their repositories / app stores.

[developomp]

@rzelnik Creating and maintaining distro-specific packages for each of the major distro's repo sounds like more work than implementing a proper update system for flatpak. Especially in the long run.

In an ideal world, we could only support flatpak as the "official" way to get anytype on Linux and pretend others options don't exist. That's what OBS, libreoffice, bottles, and many more apps are doing.

[RustoMCSpit]

any update for flatpak support?

[JustMarkov]

Any updates for flatpak?

[blacklightpy]

@rzelnik Creating and maintaining distro-specific packages for each of the major distro's repo sounds like more work than implementing a proper update system for flatpak. Especially in the long run.

In an ideal world, we could only support flatpak as the "official" way to get anytype on Linux and pretend others options don't exist. That's what OBS, libreoffice, bottles, and many more apps are doing.

That is the job of the distro maintainers, not developers. OBS, Libreoffice and Bottles do provide tons of support, but it's just that packaging for distros is not their duty, unless they also maintain them, in the repository, and not at the developer side.

One of the problems I see here is that I can't get it to build no matter what. I had to use someone else's Flatpak recipe to build a local flatpak package. I can't even figure out where to put anytype heart binaries (and custom protoc isn't building).

[developomp]

@blacklightpy

That is the job of the distro maintainers, not developers.

That is precisely my point. I am advocating that we should not do things in a distro-specific way. We're on the same page on that regard.

OBS, Libreoffice and Bottles do provide tons of support, ...

Bottles does not even accept bug reports from non-flatpak installations, and it is the norm to leave distro-specific bugs for the distro maintainers/packagers to fix so you'll have to clarify what kind of support you are talking about.

One of the problems I see here is that I can't get it to build no matter what.

Can you explain to us if there are any major technical issues preventing anytype to be built for flatpak? If the issue is with the fundamental way flatpak works and we don't have a way to fix it without major restructuring of the anytype code, we might have to look for alternative methods (such as just sticking with appimages).

[blacklightpy]

Bottles does not even accept bug reports from non-flatpak installations, and it is the norm to leave distro-specific bugs for the distro maintainers/packagers to fix so you'll have to clarify what kind of support you are talking about.

That was probably my wishful thinking coming from the fact that Flapak and LibreOffice used to be shipped long before Flatpak arrived. True, Bottles wouldn't have ever supported outside Flatpak, it's unlike something like Lutris.

Can you explain to us if there are any major technical issues preventing anytype to be built for flatpak? If the issue is with the fundamental way flatpak works and we don't have a way to fix it without major restructuring of the anytype code, we might have to look for alternative methods (such as just sticking with appimages).

No, only the Flatpak could be built, but it was from a third party (https://github.com/anyproto/anytype-ts/issues/74#issuecomment-1874126534). I recommend you guys release an official Flatpak too.

I'm using Void Linux (musl) and I couldn't get the custom protoc middleware to build. The binaries seemed to be built for musl too, but I wasn't sure how to make use of it, and the build never worked. I tried following the GitHub Actions and using electron-builder, and I had to set it to build zip / tar.gz only because FPM required for DEB/RPM was unable to find libcrypt.so.1 (probably was looking for the glibc version).

Then it seemed to show the same problems for Chromium with musl, which the Void team usually fixes with some patches. Expected since this is made with Electron. I even had to use Void's version of electron instead of the npm version in the electron builder arguments to even get it to build this much. Basically, it never goes beyond the black screen. But it's an electron problem with musl.

AppImages have a glibc dependency too, although they are working to support bundling everything. But Flatpak does package all the libraries we need, and it's also shared between apps.

The Flatpak I now have is at version 0.33.3. Official release could help me update it without manual tinkering.

[ThatOneCalculator]

+1 for Flatpak, especially since the AUR packages can be a bit finnicky

[definitelynotrazu]

+1 for Flatpak, I think it could bring in a lot of new people from Flathub