Flatpak vs AUR


  • Always prefer Free & Open-source (FOSS) software instead of proprietary.

  • Limit the amount of unofficial packages used to simplify maintenance.
    Make periodic checks on which are in actual use, and remove or replace with their official counterparts.

  • Use precaution when using packages from the AUR or an unofficial user repository.
    Most are supplied by regular users and thus may not have the same standards as those in the official repositories, therefore must be checked by you.


To improve stability and simplify maintenance:

  • Avoid cutting edge software and install only mature and proven software.
    Such packages are less likely to receive difficult upgrades such as major configuration changes or feature removals. Prefer software that has a strong and active development community, in order to simplify support in the event of a problem.

  • Avoid any use of the testing repository, even individual packages from testing.
    These packages are experimental and not suitable for a stable system.

  • Avoid packages which are built directly from upstream development sources.
    These are usually found in the AUR, with names including things like: dev, devel, svn, cvs, git, etc.


Listed by safety and stability.
Use only 1st, as the most trusted, and fallback to other sources only if you actually need it.


  1. Official repositories using pacman


    pacman -Ss PACKAGE_NAME


    pacman -Si PACKAGE_NAME


    sudo pacman -S PACKAGE_NAME
  2. Arch User Repository using AUR


    yay -Ssa PACKAGE_NAME


    yay -Sia PACKAGE_NAME


    yay -a PACKAGE_NAME
  3. Compile from Source code or create your own package using PKGBUILD.

    It’s best to create your own package, when you install program system-wide, even when you don’t intend to share it in the AUR, because pacman does a much better job than you at keeping track of files.

    If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc.

  4. Unofficial user repositories
    Adding unofficial keys


ArchWiki - System maintenance

Of course you can do whatever you want, but generally i’d say AUR is better choice for better organization, because basically what it is - a process of creating a normal Arch package from source, Flatpak could be somewhere between around 3-4.

More on AUR


The Arch User Repository (AUR) is a collection of user-submitted package description files (PKGBUILD files).
These description files can be used to create package archive files (.pkg.tar.zst files).

These PKGBUILD files can be used by an AUR helper (for example yay, paru) or manually built using makepkg.
The AUR is one of the safest ways to install software, because it is so transparent.

But it does not tolerate just looking up the package in Pamac and clicking Build button, or doing yay PACKAGE_NAME blindly. It requires that user knows what’s going on.

That’s why it is recommended to try building at least one package manually, to understand what’s going on.

yay has a nice feature that allows you to inspect a PKGBUILD file before installing, and to see the differences in the PKGBUILD file when updating a package from the AUR.

How to use AUR safely

  1. Find package on aur.archlinux.org or yay -Si PACKAGE_NAME and check:

    • Votes
    • Popularity
    • Comments (review most recent ones for red flags)
    • Maintainer
    • Last packager

    If it’s established, popular package maintained by someone who maintains a lot of other packages - chances are it’s fairly safe, usually if something fishy going on it will be removed from AUR fairly quickly.
    Otherwise be extra careful while checking PKGBUILD and / or source code!

  2. Check update frequency of the package, if it’s not some simple script or suckless software - probably better to find alternative if it’s very outdated or rarely have updates.

How to inspect the PKGBUILD file?

  1. Typically, good PKGBUILDs contain very simple instructions.

  2. Make sure all links are valid, and point to the official and trusted site of the software!
    All URLs, as well as local files expected by script, should be listed neatly in the beginning of the file in source=.
    Look for any downloads of external scripts, with curl or wget, there should not be anything like that.

  3. If there are local files or scripts listed in source=m check them for anything malicious.

  4. If the checksum variable (sha256sums=, md5sums=) contains word SKIP (usually that’s the case for *-git packages) - then the related source links should be checked more carefully, as they are not automatically verified.

  5. Check depends=, especially if they are from AUR, generally that’s very bad idea long-term.

  6. Look for anything obviously malicious:

    • rm, mv commands
    • output redirections > >> >>>
    • /dev (like /dev/null, /dev/sda, /dev/zero, /dev/random)
    • mkfs
    • calls to pacman, systemctl
    • anything that touches grub
    • encrypt unrelated files
    • mess with firewall
  7. Typically, building and installing packages should not touch anything in home directory (~, $HOME).
    If you find something like that, be very suspicious and make sure you completely understand what that command does.

  8. Look for anything that looks intentionally obfuscated:

    • anything that is written in an unclear way
    • many ;, && and ||
    • lots of brackets
    • sed, awk

Update AUR package

  1. Usually it’s only once you have to do a full review of PKGBUILD and / or source code.

  2. On update just use diff to review only changes, mostly they’re pretty small.

AUR package stopped working after system update

AUR packages are targeted at Arch stable.

When software library versions change their features and way they work can also change. These changes are normally backwards-compatible, but not always, and almost never are they forward-compatible.

This means a package built with a new library version will rarely work with an older library version (not forward-compatible), and it’s also the reason why “partial upgrades” can break things.


  1. Update your system.

  2. Rebuild AUR package.

  3. If that fails - report to AUR package maintainer via comment on AUR package page.

  4. If this fails or it’s upstream AUR program bug - report to their issue tracker.



That being said, Electron is such a crap that probably isolating it as portable system-agnostic Flatpak or appimage is not bad idea :rofl: As long as you don’t forget to update it routinely, coz Electron is…well you know, something that needs to be fixed for security and bugs routinely.


TL:DR :stuck_out_tongue_winking_eye:


IMO, you should have stopped after …

1 Like

If it’s between Electron and a Flatpak use Flatpak. As for AUR only build if you have no other choice.


Since I switched from Debian-based distros to Arch-based ones, I forgot about Flatpak, I only use AUR, with one exception where I use appimage.

flatpaks are not safer than AUR packages as a general rule.

A flatpak is a framework and packaging format. Anyone can make a flatpak. flatpaks can have malicious code just like any other package. This is true of just about any packaging format you can think of.

You shouldn’t trust a packaging format. You should trust a packaging source/packager. In other words, Arch/EOS repo packages aren’t trustworthy because they use pacman’s package format. They are trustworthy because they are packaged by Arch TUs or the EndeavourOS team.

As this relates to flatpaks, you need to look at who is packaging them. Some flatpaks are officially packaged by the team/publisher of the software. Those should be considered pretty safe. However, many are not. Then it comes down to do you trust the packager.

The sandboxing provided by flatpaks is questionable at times, depending on the application and how you want to interact with it, it may be mostly useless.

The AUR has a huge advantage when it comes to trust. That is you don’t really need to trust anyone. AUR software isn’t packaged by a 3rd party. The packages are built on your machine. The AUR PKGBUILD files which are used as the “directions” to build the software are easy to view for yourself. Many AUR helpers even offer to display them to you as part of the update process.

Of course, whether you choose to prefer flatpaks over AUR packages is entirely a matter of personal preference. The great thing is that, here, you have the ability to choose for yourself.


Should also ask about where Snaps fare in this discussion. :eyes:

The only two programs I have ever acquired from the AUR were Brave browser and Pokete game, both on Manjaro. The latter had to be build and pulled in too many dependencies in my opinion for a flimsy text-mode-only game. I was unwilling to install it as Flatpak.

In my experience Flatpak could install as many as two different versions of GNOME platform, and it would get more interesting after v44 comes out, if those apps are ever updated. I’m often not very eager necause only one “package” of GNOME platform could take as much as two-thirds of a GiB. As much as I liked the Cowsay I had to forget about it and program my own version LOL to show off to some online friends because it was cheaper in memory and it was at my short hobbyist programming reach.

Avoid the distros which put a heavy emphasis on Flatpak or any other packaging system which is not “native” like the Arch repos on Arch Linux. There seems to be an increase of distros offering only GNOME or KDE Plasma locking users into Flatpak. Tried one of them already which left a sour feeling. (Not RebornOS and I’m left with the desire to see what that “FIRE” was like!) It’s also causing me to avoid testing elementary OS although I sympathize with the story of the devs breaking up but not their begging for money for half-effort.

For me snaps are a non-starter.

I don’t want Canonical tracking every time I run an application.


I just stick with AUR. I’m not interested in using flatpaks on an Arch system.

1 Like

@Kresimir please do what you do best :frog:

1 Like

@dalto was quicker. I agree with him on this.

I would go even further, and make a claim that snapd is malware. I’ve already written about that on this forum:

There is a reason why snapd is not in Arch Linux repos, even though it is very popular on the AUR. However, the best treatment of the subject is by Linux Mint.


Completely agree.


my question might be stupid, but it is genuine…

what exactly is understood by “checking a package”? How exactly do I verify that a package is… safe? (I guess safety is what we’re checking for)
is there even a way for me to do that if I am a very “non-tech” casual user?
the only thing I can think of so far is reading comments / feedback from other users on a specific package…

the reason for these questions is probably my lack of knowledge, and I do admit that I could and probably should learn a lot of things myself, but some of the questions that I’ve been having (like the ones I’m asking here) genuinely feel like I won’t be able to just “type it in the searchbar” and find an answer…

I have a similar question here… how exactly can one check that software is mature and proven? o:

isn’t it “yay -S” for installing?.. I always use that and it works…

One way for AUR packages is to look at the build file. This requires some technical know-how still. You can see a list of build depenancies or run dependancies, but not knowing what those mean or what they do won’t help you make an informed decision still.
One way is if it’s a Flatpak, Snap, or AppImage, is it packaged/distributed by the software vendor? For example, the Microsoft Teams flatpak app in Unofficial, Microsoft releases a .deb and .rpm package for this.
It’s somewhat safe to assume if it’s in the distributions official repositories, it’s at minimum been vetted and tested and could be considered safe. Make sure you trust who is providing the distro though.

edited for typo

1 Like

There is a place in my post where you can click to open more info:

More on AUR

I can’t be more specific than that :laughing:

Research. Check how long it was around, read some comments and issues about given software, if it’s something fresh - at best try to understand quality of code yourself.

You don’t have to use -S with yay, it’s not necessary.
What -a does however is telling it to use only AUR for next operation.

yay -a - update all AUR packages
yay -a package_name - install package from AUR

That’s a great example!
If you see that something has vendor Microsoft - avoid at all cost, it is definitely a spyware.

1 Like

I would say that Flatpak vs AUR depends on what youre installing and the number of dependencies that end up coming from the AUR also.

Generally you want to treat anything not from the Arch Repos as foreign and a threat (possibly any package really). AUR and Flatpak allow you to check how things are built through either the flathubs git or through AUR pkgbuilds.

You can build flatpaks yourself (its actually pretty easy) but the ones on flathub are built from by flathub automatically from the build files similar to pkgbuilds, maintainers cant upload binary files directly for obvious reasons. AUR you build it all locally but you need to know what youre looking at to know if something is malicious in either case and need to make sure of the what and where of sources.

Ultimately it comes down to which source you trust more for a given package, some flatpaks are maintained by the original authors and very trustworthy, others arent. This also goes for AUR.

Keep in mind the flatpaks arent built by the maintainers themselves. They upload a manifest which is used by the flathub build system to actually do the build/packaging

I.E https://github.com/flathub/org.ryujinx.Ryujinx

You can also use these to build the flatpaks locally for your own repo if you wish to.

This is how flathub/flatpaks work, this process does beg the question of what kind of review process happens AFTER the initial approval and a package is added?

  1. Fork the Flathub repository on GitHub with “Copy the master branch only” unchecked.
  2. Clone the fork: git clone --branch=new-pr git@github.com:your_github_username/flathub.git
    3. Create a new branch with your app’s name: git checkout -b your_app_name
    4. Add your app’s manifest to the branch, commit it and push the commit
    5. Open a pull request against the new-pr branch on Github
    6. Your pull request will then be reviewed by the Flathub admins

Once your pull request has been approved, a new repository will be created for your application, containing your app’s Flatpak manifest. You will have write access for the repository. The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.

oh right, I should’ve read more before posting probably :"d

it’s not like I really can though… but still, thanks for the advice :"d

what happens with -S though, is it using something else outside of just AUR? What is it using? o:

No it’s just full syntax compatibility with pacman, so people wouldn’t get confused…but why use it, if you can not use it :smiley:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.