How to rebuild a package using the Arch Linux Build System -

The ABS or Arch Build System is a package building system native to the Arch Linux distribution: with it, we can easily build packages which can be installed with pacman, the distribution package manager, starting from source code. All we have to do is to specify instruction inside a PKGBUILD file and then build the package using the makepkg tool. In this tutorial we will see how to customize and re-build an already existing package.

This is a companion discussion topic for the original entry at

Great article! Very detailed, and I actually learned a couple things. There are however a couple of things I may recommend tweaking.

First, I’d suggest you make clear that base-devel is not a package, but is just a package group. Not a major distinction, and this doesn’t affect any of the steps you outlined.

Secondly, the steps to get the package building is a bit… tricky I guess. There isn’t anything outright wrong with the directions you have, but it isn’t the only way to do it. In your example, adding a gpg key to verify the upstream source is fine, however this may not translate well to other packages, either requiring a different key, different server, or no key at all. This also doesn’t apply if the modification to the PKGBUILD is specifically about changing the upstream source in the first place. If the source is trusted by the packager, and the package isn’t being distributed, it would be equally sufficient to add the --skippgpcheck to makepkg instead. Alternatively, I might recommend you more clearly explain where the key and keyserver are coming from.

Lastly, I do have to critique the method outlined to avoid package conflicts on upgrades and such. While the method suggested works, there’s actually a much easier way to do this: change the package name. In your example, we could simply edit the pkgname property in the PKGBUILD from hplip to e.g. hplip-custom. It may also be recommended to add a provides=(‘hplip’) entry too. These would accomplish 2 things: prevent pacman from trying to replace the package with the newer version of the same name, and at the same time allow it to be explicitly replaced if in the future you decide to just install the regular upstream hplip package.

I do hope I’m not coming off as too critical. Your article is indeed very well written and clear. I just see a couple of gaps that less experienced Arch users may find confusing or misunderstand.