[SOLVED] Which app version to install?

If there is a packagename version and a packagename-git version in the repository(ies), what is the difference and which one is better to install?

There are no packagename-git versions in Arch repositories, however in AUR:
packagename = release version of program
packagename-git = latest development version directly from git (if it’s complex program - it might contain more bugs and problems)

So generally it’s advisable to avoid git, unless you really need something specific at a given time or it is something very simple (like a small script or something)

Full Arch software explanation


  • 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


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.




Wow, thank you so much for that detailed answer. I was aware of the difference between the official repository and AUR/chaotic AUR. I had an uneasy feeling about git packages, now I know why, and I am glad I asked before installing anything.

Is it also fair to state that it is always better to install from the official repository rather than use an AppImage version, if that choice exists?

1 Like

Definitely, unless you have some specific problem with repo package, or there is no such program in repos or AUR at all…which is very rare

P.S. Read Full Arch software explanation in first post, it’s really full :partying_face:

1 Like

I am absolutely amazed by the wealth of app packages in the repose and AUR combined.

Thanks for clearing up these 2 points for me.
I will mark the 1st as the solution and amend the title to solved. Thank you. :pray:


Yes, that is a beauty of Arch! :penguin:

1 Like

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