The Riot Act
(Read the standing orders! Read them and understand them! ¹ )
So …
A friend … who is technical and should, therefore, know better … doesn’t have the time/inclination to build an Arch system from scratch, decided to give Garuda Linux a whirl.
It’s been gaining some notoriety of late because it’s:
- new and shiny
- very shiny
It’s basically the new pretender to Manjaro’s crown as the Arch based disto (distribution) for people who don’t have the time/inclination to build an Arch system from scratch and want to just quickly install a working system and get on with things, but do want it be an Arch system for all the benefits of a bleeding edge, rolling release distro with an established pedigree and copious resources.
To give you an idea of how much handholding it does for you, it suggests two ‘barebones’ (for ‘advanced users’ only) releases, containing ‘only the bare minimum of packages needed to get started’ … ‘for users who do not want extra software and functionalities and complain about bloat’ … that come with KDE or Gnome preinstalled! ²
Said friend has some (not entirely inconsiderable) experience with Linux, but it hasn’t been their focus — they’re much more experienced with enterprise scale Windows and a bit of a Mac guru to boot … and (unless you’re me of course 😉) you can’t be the master of everything.
So, running a domestic (or even enterprise) distro isn’t beyond them.
But Arch is neither — it’s a ‘hobbyist’/’hacker’ distro … notoriously difficult and unforgiving to ‘noobs’. After LFS (Linux From Scratch ³ ), Gentoo and (probably) Slackware, it’s the least forgiving one — if you manage to get it installed in the first place … and it even boots … it leaves you at a CLI (command line interface), with no user accounts created other than the root account, no software packages, no X Windows, no WM (window manager), no DE (desktop environment) … and, if you weren’t careful when following the installation guide, no networking, no text editor and no way to install or even configure anything else until you reboot the installation medium, retrace your steps and install/configure whatever you forgot, before crossing your fingers and trying again ⁴.
So, on the basis that the whole ‘Know <disro>, know <distro>, but know Arch and know Linux’ myth is exactly that … a myth ⁵ … if they want the benefit of my more in-depth knowledge and experience of Linux on the desktop rather than the server, they need to install Arch.
Or at least a derivative of Arch …. and one that doesn’t veer too far from the core Arch technology at that.
I’m sure. therefore, that you can imagine my response when I learned that the first thing they did after installing it wasn’t to go the Arch wiki and learn about their OS (operating system) but to go to the developer site of a particularly technologically demanding application, download the source code, compile it … (insofar as that might be even be possible, I don’t know what facility Garuda provides for that) … and try to use it.
*siii…iii…iiig*
Are they a programmer with experience as a developer?
I’ll let you guess, shall I?
Look …
Linux is not Windows — we install packages from repos (repositories), not random third-party sources.
Arch is not Debian … there are no ‘stable’, ‘testing’, ‘unstable’ versions or anything like that; there are the Core, Community and Extra repos. Don’t let those names fool you, however, they do not mean what they would in other distros and, whilst you could disable any of them, if you wanted, it would be a very short time indeed before you found yourself the owner of a machine that were horribly impoverished feature-wise and so full of security holes, it wouldn’t be funny — they are all stable (in the Arch sense of ‘stable’) … just leave them alone and let them do their thing to keep your system up-to-date
Arch is not Slackware — we don’t add random third-party repos to our sources … nor do we download sourcecode from random sites and compile it — we have no interest in developers or their code, only in things that are packaged ready for use with Arch … and we get our packages from either the official repositories or the AUR (Arch User Repository).
To update our system from the CLI, we use pacman (the Arch package manager) … or various wrappers, like pacmatic or pacnanny, to name but two … to un-/install packages from both the main repos or the AUR.
Installing things from main repos involves the use of ‘pacman -S’ (note the uppercase ‘S’) and various optional switches. There’s none of the apt-get-make-install-on-Thursday-lunchtime-if-my-left-trouser-leg-is-rolled-up-to-my-knee nonsense, just ‘pacman -S <package>’ … it really couldn’t be simpler. You can make it more complex, if you like … and have pacman automatically install dependencies, mark them as explicitly installed, whatever you like, it’s a very powerful tool — type ‘pacman --help’ for general instructions … or (for instance) ‘pacman -S --help’ for help on using the ‘-S’ switch specifically. But there’s no need to do more than ‘pacman -Syu’, if all you want to do is update your system.
Arch does not hold your hand, nor will the community — if you have a question about how something works in Arch, the answer you will most likely receive on the forums is “F**k off, read the wiki and never ask another question again or we’ll ban you!”
If you want a car you can tune yourself by hand until it’s as fast as an F1 racer, but has an Internet hub in the cockpit (from which you control your own personal Deathstar orbiting a planet in another galaxy) and a coffee-machine behind the driver’s seat, with a tube to the driver’s mouth … or even separate hot/cold coffee tubes and a third for milk (or even one for cow’s milk, one for goat’s milk, one for sheep’s milk, you get the idea) … then Arch is for you. But you’ll need to learn all about the different components that go into each of them and engineer them together yourself to work the exact way you want them to — most of the time, it’s as simple as installing whatever packages you want/need and (possibly) editing a (few) config file(s), but just occasionally, there’s some head-scratching involved and you’re pretty much left to your own devices with the aid of the Web to find out how things work at all and how they work in Linux (rather than any other OS) … and the Arch wiki in order to learn how they work in Arch specifically.
In return for your effort, you get the vehicle of your dreams, running the latest versions of the software you use as often as you can be bothered to type ‘pacman -Syu’ at the CLI.
If you want to drive a Ford Ka and take it to the garage for maintenance every six months, use another distro.
So, system maintenance is in your own hands … you can’t rely on six-monthly updates or LTS releases, you have to do it yourself (and on a regular basis)
https://wiki.archlinux.org/index.php/System_maintenance
https://wiki.archlinux.org/index.php/Pacman
https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave
https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks
What you can’t find it the main repos, you can, to varying degrees, possibly-to-probably find in the AUR: https://wiki.archlinux.org/index.php/Arch_User_Repository
Now you understand the general principles of the AUR, ignore everything in that article — it is misleading and unhelpful: you do not … EVER … go to github and download stuff from there … NEVER! … Arch is not Slackware (we don’t do that shit!)
You go to the AUR https://aur.archlinux.org/), search for the file or package you are interested in, select the result of your choice and click on ‘Download snapshot’.
You move the downloaded archive to whatever sensible location you like and extract it.
You change into the directory containing the PKGBUILD file and type ‘makepkg’.
Read any errors (usually concerning missing dependencies) and take whatever action is necessary … e.g. install missing dependencies from the repos or download them from the AUR, compile and install them in their own turn then try and compile the package again — this is the closest you will ever get to ‘dependency hell’ in Arch and you can streamline some of the process by using a different pacman option I’ll describe in a moment.
Once your package has compiled, you will have a new archive with the same package name and a suffix of ‘.pkg.tar.zst’
Type ‘pacman -U <package-name.pkg.tar.zst>’ at the CLI and your new package will be installed.
As said, you can streamline some of the process: instead of installing a missing dependency, trying makepkg again, installing the next missing dependency, trying makepkg again, etc and finally installing with ‘pacman -U’ … you can do ‘makepkg -si’ (note the lowercase ‘s’) to automatically install any dependencies it can and install the package afterwards. Obviously, YMMV, if any of the dependencies are, themselves, not in the repos and need to be downloaded from the AUR … but it can streamline things a bit at least.
That said, I prefer to do it the long way myself, because it means I get to keep my own ‘repository’ of packages with an explicit copy of their dependency trees; e.g.
[path/to /folder] /
themix/themix-full-git/build-directory/
[path/to /folder] /
themix/themix-full-git/dependencies/ themix-import-images-git/build-directory/
[path/to /folder] /
themix/themix-full-git/dependencies/ themix-import-images-git/dependencies/themix-gui-git/build-directory/
There have been a number of occasions in the Past when a package I was previously able to install from the AUR wouldn’t compile any more because one of its dependencies was no longer available (or, itself, wouldn’t compile any more, for some reason) … or the upstream sources referenced in the PKGUILD were no longer valid … and the previously compiled installable I had wouldn’t install on the new system I was using either — for architectural reasons, or because the package format changed in the meantime (which happened when the default package format was changed from tar.gz to tar.zst, for instance).
But, it’s up to you how you prefer to do this.
That all said, there have, for some years now been package management solutions made available in the AUR to facilitate / automate installation of packages from the AUR — some as command-line wrappers, others as full GUI apps.
The most famous one was Yaourt and it was available for many years, but seems to have been discontinued a while back and is no longer available in the AUR.
There are others available still: https://wiki.archlinux.org/index.php/Yaourt
In the Past, I used Kalu, but that stopped being supported a while ago now — which is a shame, because it was really useful. Kalu-KDE still works to a certain extent, but I suspect its days are numbered and, on XFCE at least, I can’t access the right-click menu to configure it any more. So, although it will still update all your packages from both the repos and the AUR, I really can’t recommend it as anything more than a handy (but, now, potentially annoying) alert system (notifying you of when there are updates to your packages from both sources).
I gave Octopi a try after that and it wasn’t horrible, but I don’t bother with that any more and just use Kalu’s notifications to alert me to available updates, doing all my installs from the CLI, with a wrapper that varies according to my mood: Pacnanny, Pacmatic or Powerpill, depending on how anal I’m feeling about the whole process … with Reflector to limit the mirrors to those in countries with good privacy laws and sorted by recency of update.
[Redacted] swears by Paru, but, as I do my AUR installs the hard way, I don’t feel the need for it myself.
However …
Garuda uses Pamac (which is available in the AUR) … a GTK3 GUI originally built for Manjaro Linux, with Alpm, AUR, Appstream, Flatpak and Snap support.
So, this is all a bit academic if you use Garuda, as you would be best advised to stick to that as much as possible, as it’s The Garuda Way … but I figured it important to cover it all, so that:
1. You understand what is going on behind the scenes when you use the Garuda package manager — it’s just Pamac, acting as a front end to Pacman, with AUR integration and you can always do it all from the CLI with Pacman (or a wrapper) instead
2. You get it right out of your head that you have any business going to random sites on the Internet, downloading source files, compiling and installing them; if you thought the likely response to questions about Arch were harsh, just see what happens if you go around telling people you need help with a package you didn’t even get from the AUR but compiled from some source you found somewhere on the Internet — it doesn’t even matter if the source came from Upstream, not only will you be told to f**k off and die … not only will you be banned from the forums … but I wouldn’t be surprised if someone were to SWAT you as well, to not simply teach you never to use Arch again and use a ‘Baby’s First Operating System’ (like Ubuntu) instead, but in the hope the police/army shoot you dead, so that you never use any technology of any kind again because you’re a moron who shouldn’t breed, let alone use Arch.
Seriously … if you aren’t an (Arch) Linux dev, you almost certainly don’t know enough about it to go around compiling from source.
The only time you might think about downloading something you can’t find with Garuda’s package manager is if it’s in the AUR but not listed in Pamac for some reason.
The only time you might even think about compiling something from source that isn’t in the AUR is if you’re bored and feeling nihilistic enough to want to do anything from wasting hours, days, weeks, months of your life trying to get something to work that has no hope of ever doing so because it’s optimised for a different system in some way and will never work on Arch … to destroying your system and having to reinstall it from scratch after losing all your data on every attached device (including network devices, connected phones, your home automation system and your bank account).
I don’t compile from source.
[Redacted] doesn’t compile from source.
YOU don’t compile from source.
You have no business going to any website other than https://archlinux.org for any reason ever — not for software, not for source code, nothing.
You barely even have reason enough to go to the upstream site to read the app specific wiki/FAQ and find out how to use it.
STAY THE F**K AWAY FROM OTHER SITES OFFERING BINARIES OR SOURCECODE!!!
(If I ever find out you’ve been downloading stuff from other sites, I will have you shaved, neutered, destroyed with fire and the earth salted for a hundred miles around your smoking ashes).
DO NOT USE ANYTHING FROM THE AUR!!!
The AUR is not safe — the stuff there is maintained by randoms on the Internet who want to do anything from helpfully make stuff available to the community … right up to emptying your bank account, incorporating your machine into a botnet and starting WW3 from it.
You have no more business using anything from there than you do compiling stuff from source — using anything from it is the equivalent of dropping your underwear in the street and grasping your ankles.
When installing stuff from the AUR, keep in mind that what the PKGBUILD does is tell the maker/compiler, where to get the source(s) from and download it.
That’s all well and good, but you have no way of knowing how the sourcefiles you are downloading got to be located at those references in the first place, nor whether the server throws in any unmentioned extras along with the original source — I was doing a build of Tagspaces and I started seeing maker/compiler messages about references to AirB’n’B (WTF!?).
The PKGBUILD for the Downgrade package, for instance, contains the following:
pkgname=downgrade
pkgver=9.0.0
pkgrel=1
pkgdesc=”Bash script for downgrading one or more packages to a version in your cache or the A.L.A.”
arch=(‘any’)
url=”https://github.com/pbrisbin/$pkgname"
license=(‘GPL’)
source=(“downgrade-v$pkgver.tar.gz::https://github.com/pbrisbin/$pkgname/archive/v$pkgver.tar.gz")
depends=(‘pacman-contrib’) # pacsort
optdepends=(‘sudo: for installation via sudo’)package() { cd “$pkgname-$pkgver” || exit 1
make DESTDIR=”$pkgdir” PREFIX=/usr install } md5sums=(‘f37e1c3c70d6b1292c7ea3499eebab87’)
Okay, so, what exactly is it going to download from https://github.com/pbrisbin/downgrade?
And what’s in https://github.com/pbrisbin/$pkgname/archive/v$pkgver.tar.gz precisely?
And once it’s downloaded and the maker/compiler starts work on it, what else gets called upon and downloaded (and where from)?
Unfortunately, sometimes, even though it could not ever be said that we had no choice, we give in to our urges nevertheless and insist on slaking our unnatural desires with something that isn’t available in the main repos.
I can maybe impress upon you the fact that, if you ever compile anything from source, I will find you and put you down like the dog you are, but even I know I won’t be able to be vigilant all the time and, sooner rather than later, you will foolishly install something from the AUR.
I’m resigned to that inevitability.
But at least I can make you aware that it’s a cesspool and you could end up being tag-raped by seven UFC fighters in the back of a Ford Focus for your troubles.
Use it at your own risk.
I’d suggest that, before, you install any packages from outside the default Core/Extra/Community repos, you go to the Upstream git and take a look at whatever you can find there, before you tell Pacman (or whatever) to install them.
Better yet, go to the relevant page for the package in the AUR, download the snapshot, take a look in the PKGBUILD (and .SRCINFO, if there is one), check whether what’s in there does indeed point to the Upstream source(s) or if it points to somewhere else (as well), compare any third party site references with the Upstream source (makes sure the AUR version isn’t slipping in anything that isn’t in the original) and only when you’re happy that it’s all aboveboard install/update it.
If you really, absolutely, cannot but try building something from source … and you can hide yourself away in a remote, underground cave system long enough to do so before I find and exterminate you, you do it the Arch way, by creating a PKGBUILD, a .SRCINFO and installing even your own app (that you coded yourself from scratch) as if you’d downloaded it from the AUR
https://wiki.archlinux.org/index.php/Arch_Build_System
https://wiki.archlinux.org/index.php/Creating_packages
https://wiki.archlinux.org/index.php/Arch_package_guidelines
https://wiki.archlinux.org/index.php/Pkgbuild
https://wiki.archlinux.org/index.php/.SRCINFO
https://wiki.archlinux.org/index.php/Makepkg
However …
DON’T DO IT!!!
EVER!!!
I will hunt you down.
I will find you.
I will give you a barbed-wire enema and repeatedly dunk you head-first into a bucket of liquefied dog-crap until you drown..
Your end will be both horrifying and ignominious — you will die with not even a whimper, let alone a bang … but upside-down, in a bucket of dog-shit.
DON’T DO IT!!!
Got it?
Right … with all that said … really, the safest way to add software that isn’t in the main repos is to download the original source and compile it yourself — you can look at it, audit it and (if you’re a good enough programmer) determine that it’s safe — stuff you get from the AUR makes calls to random web/ftp/whatever sites … that, themselves, might include stuff from who knows where else … and compiles it all into a binary, the workings of which are a complete mystery (which is just asking for trouble).
But you shouldn’t be doing that until you understand how Arch manages packages and how you go about compiling and installing things the Arch way.
So, read the links and the Arch wiki! Read them and understand them!
You have no business installing third party software until you have.
²
³ Which is an educational project, not a distro as such.
⁴ You can see why someone would be interested in a bleeding edge, rolling release distro with an established pedigree and copious resources that they can install without all the work.
And you can see why I’d have to bite my tongue as well, whenever they mentioned it.
⁵ I don’t know Linux … I know Arch — if you want help with Ubuntu (or whatever), you’re on your own, I’m afraid, because I don’t know what it installs, where it installs it, how it’s configured, what tools are available to administer the system, where they are … it’s as much (if not more) a mystery to me as it is to you.
