Why using custom AppImages instead of .tar.gz binaries provided by the developer? And some other questions.

[sbstn87]

Hello,

I was wondering about a few things regarding Soar:

1. Why does it use AppImages even when much smaller .tar.gz binaries are available? For example: LocalSend, CopyQ.
2. Why does it often use custom ('Enhanced') AppImages with different GitHub repos even when "official" AppImages are provided by the developer? For example: LocalSend, Sayonara Player, CopyQ.
3. Would it be beneficial and possible to use native .deb/.rpm packages when they are provided by the developer instead of AppImages? Download size would be much smaller and (I assume) compatibility/integration with the underlying system would be better. Of course this would happen only when Soar recognizes it is run on a .deb/.rpm distro.

[Samueru-sama]

1. Why does it use AppImages even when much smaller .tar.gz binaries are available? For example: LocalSend, CopyQ.

Unless those binaries are static, they are not ideal since they won't work on all linux systems.

Why does it often use custom ('Enhanced') AppImages with different GitHub repos even when "official" AppImages are provided by the developer? For example: LocalSend, Sayonara Player, CopyQ.

Because those official appimages don't work on all linux systems. See pkgforge-dev/Anylinux-AppImages#269

Download size would be much smaller and (I assume)

Unlikely

[sbstn87]

If you can create AppImages that work everywhere, why are not all AppImages made in a way that makes them work on all Linux systems? Aren't they somehow standardized?

I assume this causes a significant overhead and maintenance work for you if you have to create new AppImages for the covered software.

---

How is this possible that AppImages require less disk space than Flatpaks? Flatpaks share dependencies, whereas every AppImage has to bundle all dependencies separately. So at a worst case scenario when every Flatpak app requires completely different dependencies, it will take the same space as AppImages.

[Samueru-sama]

If you can create AppImages that work everywhere, why are not all AppImages made in a way that makes them work on all Linux systems?

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/main/FAQ.md#how-come-this-only-became-possible-in-2024

How is this possible that AppImages require less disk space than Flatpaks? Flatpaks share dependencies

• Sharing dependencies means very little when the flatpak runtimes are essentially full blown distros, and some like the GNOME runtime have a very short support period so you often end up with several versions of it installed.

• And flatpaks don't really share dependencies that much btw, a lot of flatpaks end up needing to vendor in their own dependencies due to having xyz issue with the version provided by the flatpak runtime, for example mpv flatpak ships its own ffmpeg.

So at a worst case scenario when every Flatpak app requires completely different dependencies, it will take the same space as AppImages.

We also optimize the size of our dependencies

[QaidVoid]

Would it be beneficial and possible to use native .deb/.rpm packages when they are provided by the developer instead of AppImages? Download size would be much smaller and (I assume) compatibility/integration with the underlying system would be better.

.deb/.rpm would actually make compatibility worse, not better. They're built against a specific distro's dependency versions, and neither works at all on musl systems like Alpine. That's the opposite of what Soar is trying to do: one binary that works everywhere.

If you want native package integration specifically, apt/dnf already handle that better since they resolve deps against your actual system anyway.

[sbstn87]

What are the drawbacks/limitations when using soar vs system native packages like .deb/.rpm? I supposed that disk space usage will be higher, but is there anything else worth noting like issues with theming or some file acces problems?

[QaidVoid]

What are the drawbacks/limitations when using soar vs system native packages

Soar doesn't install services or config files under /etc, and doesn't manage users/groups, kernel modules, etc.

I supposed that disk space usage will be higher

Most of the static binaries are roughly the same size as dynamic ones. And it depends on how the distro builds packages. If upstream ships size-optimized builds and the distro doesn't, soar's can end up smaller.

For GUI apps, it depends on whether the deps are shared. Install a single Qt app, and you pull the whole Qt stack just to run one app. In such case, AppImage can be smaller.

is there anything else worth noting like issues with theming or some file acces problems

That depends on the package itself. Soar installs packages exactly as published..