User:Regid/AUR/*-git AUR packages

Related articles

• git

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, torsocks-git^AUR.

Retrieve for the 1st time

This operation is similar to retrieving any package from the AUR. For example, referring to the example package of torsocks-git^AUR,

$ 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 PKGBUILD.

Extract the source

While in the PKGBUILD directory,

$ 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.

Tip: It is suggested to create a local branch, and switched to it, to separate any local modifications to the source from the upstream versions.

Build

While in the PKGBUILD directory, use your usual build command, such as

$ LC_ALL=C makepkg --log --nocolor --noextract

The updated 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.

Install

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.

Update

This can be divided into

1. Updating the package retrieved from the AUR
2. 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 PKGBUILD directory:

$ 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.

Run

$ 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 PKGBUILD directory.

Both will synchronize the local bare git repository to the remote one. And then, from the actual src/pkgname directory, src/torsocks for the concrete example, run

$ git pull

or

$ git pull |& less

And

$ git fetch --tags