I use various suckless(or suckless like) software, including the window manager, the “run” launcher, the status bar and the terminal on my Linux machine.

One of the main features of these “suckless-like” software is that they have to be built from the source since that is the only way for configuration. The typical installation comprises these steps:

• You get the source code itself(for instance, through git clone),
• You modify the source code or apply patches to add features not available in the vanilla build,
• You run make, and if compilation is successful, make install to install the built binary.

However, these are not managed by the package manager, creating issues with dependency management. My build requires additional dependencies(and thus not documented upstream), and removing them might leave their dependencies around.

Also, if I migrate my setup, I can have most of my packages installed using a single command, thanks to a generated list from the package manager. But it would require the “clone-make-make install” ritual for the source builds.

It led me to consider making binary packages of my custom suckless software, requiring me to write a package description file(also known as PKGBUILD in Arch-based distros)…

“… and posting them to the AUR.” would be the first guess for any Arch user. However, it is possible to have these packages removed from the AUR as these are merely user-specific builds of another software. Thus I would have to make my package repository.

Making the package repository(and automating it) ¶

A package repository contains some package files(among others) having the extension pkg.tar.zst. Navigating to a specific address based on the directory listing of these files would provide you with the actual package file.

I figured GitHub pages would be best suited for it. I could have a repository having a os/x86_64 folder and dump all the built packages there.

So I went looking for guides for writing PKGBUILDs and creating user repositories. But most of them rely on manually building the packages, manually copying packages to the database, manually building the database repo, and manually pushing the changes along with the updated packages to the remote. Too much manual interference is something I would rather not have in my setup, and thus led me to use GitHub Actions for automation.

Having no experience, using it was easy due to its YAML syntax. I chained together multiple actions to suit my purpose.

My source repositories can have multiple commits a day, and I wouldn’t want to trigger the action on every push. They are instead triggered by a change to the PKGBUILDs. Here is how it is wired, as of writing this blog:

• I push the updated source code to the source repo,
• I push the updated PKGBUILD to the package repo, triggering a build of the new package,
• The package is then committed to the database repo,
• The database then builds itself, incorporating the new packages.

Packages available in the repo ¶

Currently, the following packages are available in the repository:

Since this blog was published some of the packages have been deprecated and others were moved to this monorepo. The links below are kept as-is for archival purposes.

• dmenu-royarg-git
• dwm-royarg-git
• dwmblocks-royarg-git
• lf-royarg-bin
• slock-royarg-git
• st-royarg-git

The built package files are located here. Instructions to have these packages are in the README or can be found directly at https://royarg02.github.io/royarg-repo.

With that said, if you want to, go ahead and try those packages!

Until next time.