Why EOS should include flatpak by default? (or at least consider doing so)

The reasons or the PROs of flatpak over the AUR/Arch repos are below.

  • Many distros especially newbie friendly ones include it OOTB.
  • Since they are often the application maintainer’s official package, flatpaks are generally more up to do date and are prone to less packaging issues unlike packages in the AUR or even the ones in the main repos.
  • Flatpak packages rarely, if ever cause dependency hell.
  • Flatpak apps can be installed on the user level.
  • Flatpak packages are more private and secure due to them being sandboxed.
  • Flatpaks also integrate into GNOME Software and KDE’s Discover unlike the AUR which makes it far easier for newbies to install them or find information/documentation on the application they contain.
  • Many third-party apps can only be found in flathub.

I think making flatpak (which in many ways fills in the holes of the other packaging formats) available OOTB can only be beneficial for EOS as it would make it more convenient and user friendly. And for users who don’t want it, they always have the option to remove it.

If you want to go ahead and do so, please include the xdg-desktop-portal-gtk package in the Plasma edition with flatpak so that the flatpak packages follow the system theme.

And if you still don’t want to include it OOTB in the distro, please at the very least include it as an unchecked option in the “Package Selection” section of the online install.

Thanks for reading!


Or - here’s a radical idea - for users who want it, they always have the option to install it.


Dear Danish Rehman @amethystgosling,

You have already made several similar topics asking for packages or features to be added to EnOS.

And the Devs and other forum members have kindly responded to you that:

EndeavourOS provides an almost close to vanilla Arch set up out of the box.

It installs a minimal set of a packages and is minimally configured.

It is to be considered as a blank canvas on which users according their needs will create the most artful systems.

After the installation (and even in the live iso using a custom package list) each users can add whatever packages they want to their heart content.

Feel free to spend your time creating similar topics but I doubt the response would be any different.




That is not what EOS is about. If you want something convenient and user friendly then you should be looking at a distro like linux mint. Arch and arch-based distro’s are not for people who want convenient and user friendly.

I am not on the development team, but i can tell you posts/suggestions about ‘making EOS more user friendly’ are never implemented. EOS is aimed at intermediate users, not newbies wanting user friendly.


It’s a terrible idea. I certainly wouldn’t use any distro that included such bloat by default.

You are not only free to, but also encouraged to use any of those other distros, if they fit your use case better than EndeavourOS.

EndeavourOS is not the only distro in the universe, and it’s not the best distro for everyone.

Quite the contrary. Many flatpaks are maintained by a third-party. The packaging is not transparent and you cannot really know what is included in those packages – it could be malicious.

Furthermore, even the flatpaks that are maintained by the developers of the software in question (which you assume to be trustworthy, otherwise you wouldn’t use that software) are potentially insecure, because they are statically linked with their dependencies, which means that libraries included in flatpaks can be out of date and thus contain security vulnerabilities, regressions and bugs.

Packages in the official repos are not at all prone to “packaging issues” (whatever those are), and if there is a bug found in the official packages, it can be reported and more often than not, it will be quickly fixed.

Neither do the packages from the official repos. Sometimes, you will find AUR packages that fail to build with updated dependencies (and usually, soyftware developers and their npm-mindset are to blame for including many unnecessary dependencies), but with official packages, that’s not a concern.

This does not follow. Flatpaks set their own sandboxing rules and they can contain malicious code. The sandboxing is a mere illusion of privacy and security, if what the packaging contains is intentionally insecure.

You shouldn’t be using ɢɴᴏᴍᴇ Soyftware and KDE Discover on Arch or its derivatives, anyway. So this is not a problem.

On EndeavourOS, graphical package managers are not supported.

Most of them are also in the AUR. Besides, you can use flatpaks on Arch, you just have to install it.




It’s what the developer tested against (if at all). If you need newer libraries, you become the QA / lab rabbit (or should I have said “lab frog” :wink: ?)

And if a security vulnerability is discovered in those dependencies and the developers do not release an updated flatpak in time? You not only have vulnerable software, but malicious actors have a written step-by-step guide on how to exploit your vulnerable software.


Arch and EndeavoursOS are DIY distributions, the on difference between them is that EndeavourOS gives you a graphical installation process which gives you a working installation after which you can do it yourself because both Arch and EndeavourOS are DIY distributions. If you want something more user friendly than EndeavoursOS just use Fedora which has Flatpak installed by default already.


You have a couple of options, then:

  • Recompile the software against newer dependencies / trust your distro maintainers to do the same. As always with open source (and almost always with closed source), you become the QA in this case.
  • Continue using the software in spite of the vulnerabilities
  • Move to a different software

…or use the software from the repos, like the good Lord intended. :rofl:


I haven’t come across a third-party app yet that was not found in the AUR.

It’s the first case, namely, you’re the QA.

That’s just wrong. At least on Arch, package maintainers almost always thoroughly test software before pushing updates to the official stable repos. For more critical and complex software, it can be held in the testing repos for months before being pushed to stable repos.

Also, since most software is dynamically linked, libraries can be updated with security fixes without updating the actual programs. That’s the main benefit of dynamically linking code. Of lesser importance is the fact that it also saves storage space, since libraries are not duplicated for every program that uses them.


The minute we go flatpak I’m out! :rofl:


Flatpak “runtimes” are actually intended to partially avoid duplication.

As they say, YMMV. Sometimes Flatpak / AppImage work better than the packages from the repos (happened to me with e.g. Digikam), and sometimes it’s the opposite.

Maniatic Launcher for example is only available on Flathub.

1 Like

But, but… that’s 𝖆𝖇𝖘𝖔𝖑𝖚𝖙𝖊𝖑𝖞 𝖕𝖗𝖔𝖕𝖗𝖎𝖊𝖙𝖆𝖗𝖞! :face_vomiting:

1 Like

Noobs have lots of distros already

The good thing about EOS is that it bridges the gap between something like Manjaro or typing hundreds of lines of code to install a system

1 Like

I am against this as for many reasons other users already stated

The only thing that might be a possibility is to include it in the installer but disabled by default.
That way the user has the option to include it if they want