Last night while updating my system, I noticed that a random aur package my system depends on was orphaned in the aur. It’s some random deep-down dependency of another AUR package, and it’s not received any upstream commits in a while. Nice and stable, just needed an owner. I decided to adopt the package before someone else did.
It was kinda scary how simple it is to adopt an orphaned package. Create AUR account… click an email link… Done. If someone wanted to squat the package for malicious purposes, it would be stupidly simple.
I get that this is a problem for all community repos, not just AUR (npm, anyone?), but it’s still an unsettling prospect. I feel like it goes unacknowledged some times.
This is the main reason that one should learn to read PKGBUILDs. Any AUR helper like Yay or Paru should give the option. Just make sure that the package downloads from an official source and contains only the necessary build and install instructions.
But I agree. Some people treat the AUR as just another repository, when it most definitely is not.
This is something that I still need to learn about. What is a good starting point to learn how to read them?
First, you should be familiar with the basic process of compiling and installing software from source. For C or C++ projects, this can be as simple as
./configure
,make
,make install
for projects that use GNU Autotools, or something likecmake -B build
,cd build
,make
,make install
for CMake projects.I generally split PKGBUILDs into three important parts. There’s the metadata at the top then there’s the
build
andpackage
functions.build
is where everything up to themake
(or equivalent build-the-thing) command goes andpackage
is where themake install
bits go.There’s also the
prepare
andcheck
functions, but those aren’t used as often.As for the actual documentation, the Arch Wiki page for PKGBUILD covers most of the metadata stuff and the page for Creating Packages covers most of the
build
andpackage
stuff.It’s a shell script. Somebody wrote down the shell commands to download, extract, compile from source code. If you can do shell stuff then you’re about 1/2 way there. If you’ve ever manually compiled from source code then you’re all the way there pretty much.
It’s quite simple since there isn’t any other abstraction to learn than what many Linux users already know. Shell commands and compiling stuff.
Probably the one thing that might be foreign is variable and functions of shell scripting.