One of the easiest ways to contribute to Arch is to maintain a package, or packages, in the AUR; the repository of user contributed PKGBUILDs that extends the range of packages available for Arch by some magnitude. Given that PKGBUILDs are just shell scripts, the barrier to entry is relatively low, and investing the small amount of effort required to clear that barrier will not only give you a much better understanding of how packaging works in Arch, but will scratch your own itch for a particular package and hopefully assuage someone else’s similar desire at the same time.
Now that I have a Raspberry Pi1, I am naturally much more interested in packages that can be built for the ARMv6 architecture; especially those that are available in the AUR. It is worth a brief digression to note that Arch Linux ARM is an entirely separate distribution and, while they share features with Arch, support for each is restricted to their respective communities. It is with this consideration in mind that I had begun to think about multi-arch support in PKGBUILDs, particularly in the packages that I maintain in the AUR.
I have previously posted about using Syncthing across my network, including on a Pi as one of the nodes. As the Syncthing developer pushes out a release at least weekly, I have been maintaining my own PKGBUILD and, after Syncthing was pulled into [community], I uploaded it to the AUR as syncthing-bin.
Syncthing is a cross platform application so it runs on a wide range of
architectures, including ARM (both v6 and v7). Initially, when I wrote the
PKGBUILD, I would
updpkgsums on my x86_64 machine, build the package and
then, on the Pi, have to regenerate the integrity checks. This was manageable
enough for my own use across two architectures, but wasn’t really going to
work for people using other architectures (especially if they are using
Naturally enough, this started me thinking about how I could more effectively manage the process of updating the PKGBUILD for each new release, and have it work across the four architectures—without having to manually copy and paste or anything similarly tedious. Managing multiple architectures in the PKGBUILD itself is not particularly problematic, a case statement is sufficient:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
The real challenge, for me, was to be able to script the replacement of each of the respective sha1sums, and then to update the PKGBUILD with the new arrays. Each release of Syncthing is accompanied by a text file containing all of the sha1sums, each on its own line in a conveniently ordered format, like so:
1 2 3 4
This seemed a perfect job for Awk, or more particularly,
and an admittedly rather convoluted
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
The remaining step was to update the PKGBUILD with the new sha1sums. Fortunately,
Dave Reisner had already written the code
for this in his
updpkgsums utility; I had only to adapt it slightly:
1 2 3 4 5 6 7 8 9 10
Combining these two tasks means that I have a script that, when run, will download
the current Syncthing release’s sha1sum.txt.asc
file, extract the relevant sums into the replacement case statement and then
write it into the PKGBUILD. I can then run
makepkg -ci && mkaurball, upload
the new tarball to the AUR and the two other people that are using the PKGBUILD
can download it and not have to generate new sums before installing their
shiny, new version of Syncthing. You can see the full version of the script in
my bitbucket repo.
- See my other posts about the Pi…
Creative Commons image of the Mosque at Agra, by yours truly.