This article presents a shallow view of the AUR -git packages. Yet it does attempt to view it from above. Hopefully, even though it is a shallow view, it will enable many users to exploit their advantages. Superficial acquaintance with git can be helpful, but is not required.
Many AUR packages allow building packages from their respective upstream git repository. Common names of such packages have a -git suffix, though such a name is not mandatory. Building, and using, such packages can be an alternative, which can be more strictly controlled, over using the testing and the staging repositories. In addition, there are -git AUR packages which are not part of these repositories.
The -git packages download a local git repository for each -git package. On the negative side, for large software packages, downloading the git repository requires more resources. Due to the usage of a version controlled system, the -git packages offer an alternative path for obtaining, and tracking, the source of such packages. The emphasize of this article will be on the alternative path.
In total, there are 3 git repositories involved. One repository is for the Archlinux package. And 2 repositories are for the package itself.
This article will use the torsocks package as a concrete example. That is, AUR.
Retrieve for the 1st time
This operation is similar to retrieving any package from the AUR. For example, referring to the example package ofAUR,
$ git clone https://aur.arhlinux.org/torsocks-git.git
The title here mentions `1st time' because the emphasis is on exploiting the git version control system. If that is not desired, one can follow the usual procedures for building packages from the AUR.
After installation, one usually have a new directory, with few files that were downloaded. A notable exception in the -git packages case, which does not always occurs, is that the version mentioned in the
pkgver field of the
PKGBUILD file is not the up to date version. Another difference between the usual, and the -git PKGBUILD, is that the later has a
pkgver(), or similarly named, function. Once again, there are exceptions. The
pkgver() function is how, later on, the
pkgver field will get its up to date value.
Retrieve the source
Once again, one can follow the usual AUR packages procedures. For better understanding, which can be beneficial later, here is the same results, in a slower pace.
$ LC_ALL=C makepkg --verifysource
This will download the source, if it is not already fetched. In contrast to usual procedure, it does not fetch a tar ball. It does, however, create a directory. Usually named after the package name. torsocks, in the article concrete example. Inside that directory it places a git bare repository.
Verification is skipped since, usually, there are no PKGBUILD#integrity field, and there is no
validpgpkeys array in the
Extract the source
While in the
$ LC_ALL=C makepkg --log --nocolor --nobuild
This creates the usual
src/pkgname directory, with the source within it. It does that by pulling the source from the local bare git repository mentioned earlier. It also places the source under another git repository, so that when the bare git repository is fetched a newer version, this source can be updated.
While in the
PKGBUILD directory, use your usual build command, such as
$ LC_ALL=C makepkg --log --nocolor --noextract
pkgver is not evident at the 1st line of
makepkg output. It can be seen only a few lines downwards. If
--log was requested, there will also be a
*-pkgver.log file, detailing the history of the
pkgver values. There can be a revision number embedded in the names, denoted with, or without, the letter
r. Or part of a commit number, preceded by
g. These also can ease identifying the revisions of the build, and the git commits they are related to.
The build will use whatever branch the local source,
src/pakgname, is switched to. Which is one of the strengths of the whole -git package.
Installing the package is not different from installing any other local package.
It is worth mentioning that the -git package is very likely to conflict the non -git package, if one is installed. If the name, version and release were not changed in
PKGBUILD, then there is no prior need to worry about how pacman will deal with having 2 similar packages installed.
This can be divided into
- Updating the package retrieved from the AUR
- Updating the software package
Updating the package retrieved from the AUR
The Archlinux maintainer can decide that he has some reasons to update the AUR package. It doesn't occur often, but should be aware of. One way to find out is to run, while in the
$ git pull --dry-run --verbose
From https://aur.archlinux.org/torsocks-git = [up to date] master -> origin/master
Updating the software package
More often, there will be new upstream commits for the package itself.
$ git fetch
in the bare git repository directory. The torsocks directory for the concrete example. Or, as before,
$ LC_ALL=C makepkg --verifysource
while in the
Both will synchronize the local bare git repository to the remote one. And then, from the actual
src/torsocks for the concrete example, run
$ git pull
$ git pull |& less
$ git fetch --tags