anytype-ts
anytype-ts copied to clipboard
anyproto
Limit Linux app distribution methods to AppImage and flatpak
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.
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.
@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.
@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).
@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).
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.
+1 for Flatpak, especially since the AUR packages can be a bit finnicky
+1 for Flatpak, I think it could bring in a lot of new people from Flathub
Bringing Anytype into Flatpak via Flathub also allow people to see this undiscovered gem from software stores. Anytype is a gem for open source community. Let the people discover.
Seems that it's now on Flathub – but uses X11 as the default session? https://flathub.org/apps/io.anytype.anytype
Anytype is a gem for open source community
@Tahinli keep in mind that Anytype is source available, not open source.
Seems that it's now on Flathub – but uses X11 as the default session? https://flathub.org/apps/io.anytype.anytype
That's an unofficial community-maintained package.
Anytype is a gem for open source community
@Tahinli keep in mind that Anytype is source available, not open source.
Does this makes Anytype proprietary. I read the license and seems like Anytype says "Hey we did the app and only we can edit the code and redistribute it, but here is our code if you want to audit."
I understand that it's not open source but since we can see code does it still counts as proprietary ?
(Screenshot from Flathub)
Getting a bit off-topic from this issue, but made an issue with Flathub here: https://github.com/flathub-infra/website/issues/4029
@developomp
That's an unofficial community-maintained package.
It's now verified, isn't it?
@Tahinli
I read the license and seems like Anytype says "Hey we did the app and only we can edit the code and redistribute it, but here is our code if you want to audit."
No, you can edit, redistribute, and do whatever you want with the code/the app, as long as it's not for commercial purposes, see https://github.com/anyproto/anytype-ts/blob/main/LICENSE.md
“Non-Commercial Use” means personal, academic, scientific, or research and development use, or evaluating the Software, but does not include uses where the Software facilitates any transaction of economic value other than on Allowed Networks.
To “use” means any use, modification, distribution or other exploitation of the Software or any part of it.
Also, please see https://community.anytype.io/t/how-does-the-anytype-license-apply-to-self-hosting-internal-deployments-in-commercial-contexts/12322
@developomp
That's an unofficial community-maintained package.
It's now verified, isn't it?
@Tahinli
I read the license and seems like Anytype says "Hey we did the app and only we can edit the code and redistribute it, but here is our code if you want to audit."
No, you can edit, redistribute, and do whatever you want with the code/the app, as long as it's not for commercial purposes, see https://github.com/anyproto/anytype-ts/blob/main/LICENSE.md
“Non-Commercial Use” means personal, academic, scientific, or research and development use, or evaluating the Software, but does not include uses where the Software facilitates any transaction of economic value other than on Allowed Networks.
To “use” means any use, modification, distribution or other exploitation of the Software or any part of it.
Also, please see https://community.anytype.io/t/how-does-the-anytype-license-apply-to-self-hosting-internal-deployments-in-commercial-contexts/12322
Yeah, it seems verified and thanks for license clarification.