AUR packaging: my workflow

Introduction

I got into AUR packaging a couple of months ago. My first contact with AUR as a maintainer was due to the package hypnotix-wayland, a custom build (literally just one line of Python added) of the IPTV streaming application made by Linux Mint guys, being orphaned and not working because of an update of the source code. Until that moment I never opened a PKGBUILD and had no idea of how it worked, but after half an hour of Arch Wiki reading I could understand most of the PKGBUILD content and I easily fixed the problem. At that point, I thought "Yeah, why not?" and signed up on the AUR website to adopt the package.

After that, I adopted a couple more packages and their dependencies, so my initial unstructured approach to PKGBUILD editing had to evolve into a more linear workflow. After a couple of tries, I found the optimal solution in terms of sticking with best practices and minimizing the time spent for every version bump.

The Flow™

I divided the workflow into three main sections:

All of them will be covered in the next paragraphs.

The Flow

Check Stage

The update of a package starts accordingly with my free time, as in "Today I haven't checked my packages yet, this is a nice excuse to stop immediately what I'm doing and take a break!"

I decided to not fully automate this part because I don't want to make it feel like a job. But if you want to automate it it's a matter of a Cron job or a SystemD Timer.

nvchecker

nvchecker is a godsent tool to programmatically check if some piece of software had any new release. It supports various sources like Github, PyPI, and many more.

It's super easy to use, to add software in the configuration is just a matter of:

[SubDomainizer]
source = "github"
github = "nsonaniya2010/SubDomainizer"
use_latest_release=true

It saves the current version of every software from the config file in a JSON, and then at every run, it checks if there is a new version.

I know a lot of people prefer urlwatch, but I didn't get along well with it.

So, at this point, if nvchecker detects any update we enter the Edit stage.

Edit Stage

First thing first we need the get the current PKGBUILD, if I already have it on the PC I'm working on (I usually update packages from multiple PCs, like my personal or the work's one) I just do a git pull in the repo, if not I clone it.

Most of the time the upgrade is just a matter of changing the version and updating the sums, but sometimes fixes or changes are required. There's no way to automate those, so I need to do them manually.

updpkgsums

Updating the package sums is not fun work to do though, so obviously someone already automated it. You can find updpkgsums in the official Arch repos in the pacman-contrib package. Just launch it in the PKGBUILD's directory and the problem is solved.

After that, I usually forgot to launch makepkg --printsrcinfo > .SRCINFO to copy the updated sums and versions to the .SRCINFO file, but I usually remember some steps later.

namcap

Ok, most of the work is done, but what if I missed something in the PKGBUILD, like a tag or similar? I won't get that as an error during the build, we need some kind of linter for that. Searching around I found namcap, it makes a lot of checks on the PKGBUILD and tells you if something is missing. It's especially useful during package creation.

Build Stage

Now it's time for the build, if we missed some dependency or malformed the PKGBUILD we will discover it here.

paru vs makepkg

To build and install the packages I currently use paru -Ui instead of makepkg -sri mainly because of the AUR dependencies. If your package has any dependency not in the official repos, makepkg will not be able to install them.

After building and installing the package on my system, I test the package manually trying to launch it and checking that everything is working. But if it builds on my system does it mathematically builds on yours? Nope.

aur-pkgbuild-tester

To make a real build test we need a clean environment. While searching for a solution I stumbled upon this script. It pulls an Arch Linux Docker image, installs all the base stuff, the package's dependencies and builds the package. Now, I had one problem with this script: it uses yay for dependency but without the flag for installing dependencies from AUR, so if you have any dependency from there, the package won't build. I decided to fix this issue using paru instead of yay, so I forked it. You can find my fork here.

End

After building and testing, if everything is working I call it a day and push to AUR, if not I just go back to the Edit Stage and repeat all the steps.

BONUS: Nightly check for builds

What if a dependency changes name overnight and your package build starts failing? Yeah, it happened to me, more or less.

Luckily I found this awesome Github pipeline that runs every night building your packages. If some package fails to build, you will receive an email. So I just created a Github repo with all my AUR repos as submodules, modified the pipeline a little to suit my needs, and now I don't worry anymore about packages that for some reason stop building.