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
SAFETY
-
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.
STABILITY
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.
SOFTWARE
Listed by safety and stability.
Use only 1st, as the most trusted, and fallback to other sources only if you actually need it.
Arch
-
Official repositories using pacman
Search
pacman -Ss PACKAGE_NAME
Information
pacman -Si PACKAGE_NAME
Install
sudo pacman -S PACKAGE_NAME
-
Arch User Repository using AUR
Search
yay -Ssa PACKAGE_NAME
Information
yay -Sia PACKAGE_NAME
Install
yay -a PACKAGE_NAME
-
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.
Sources
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
-
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 checkingPKGBUILD
and / or source code! -
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?
-
Typically, good
PKGBUILD
s contain very simple instructions. -
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 insource=
.
Look for any downloads of external scripts, withcurl
orwget
, there should not be anything like that. -
If there are local files or scripts listed in
source=
m check them for anything malicious. -
If the checksum variable (
sha256sums=
,md5sums=
) contains wordSKIP
(usually that’s the case for*-git
packages) - then the related source links should be checked more carefully, as they are not automatically verified. -
Check
depends=
, especially if they are from AUR, generally that’s very bad idea long-term. -
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
-
-
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. -
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
-
Usually it’s only once you have to do a full review of
PKGBUILD
and / or source code. -
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.
Solutions
-
Update your system.
-
Rebuild AUR package.
-
If that fails - report to AUR package maintainer via comment on AUR package page.
-
If this fails or it’s upstream AUR program bug - report to their issue tracker.
Sources
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?
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
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.
Yes, that is a beauty of Arch!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.