tur ships prebuilt Termux packages so you do not compile on the phone

Why compiling on a phone is the problem

The README opens by comparing the project to the Arch Linux User Repository and then immediately says the mechanism is different. The point is that instead of building packages in the device, which in Android is quite hectic work for the user, TUR saves resources and time since the user can install a pre-compiled package. That distinction is the whole design. An AUR style repository asks you to run a build script on your own machine, which on a phone means a toolchain, hours of CPU and heat, and a build that may fail because the device is short on memory or the source expects a toolchain version you do not have. TUR instead has a build machine somewhere else and you install a finished deb. The list of problems TUR says it solves is worth reading in order. Less popular packages can be added. Many Python, Node and Ruby packages need compilation in the device, and TUR makes installation easy by distributing a deb file. Instead of hosting your own APT repository, one could add their package in TUR. There is one place for all packages which could not be part of the official Termux repo for some reason. And old versions of packages are available in TUR. That last point is the one that distinguishes it from the official repository rather than extending it. The official Termux repo tracks current versions; TUR also keeps old ones, which is what you need when a package you depend on has not been rebuilt for the current Android API level. The audience is Termux users on Android who need a package the official repository does not carry.

Subscribing with tur-repo, and the three default components

Adding the repository to Termux takes one command.

pkg install tur-repo

Once tur-repo is installed, TUR packages can be installed with pkg or apt in the same ways as any other repository. The important detail, and the one that trips people up, is that the TUR APT repository consists of many components, and only three of them are available by default: tur, tur-on-device and tur-continuous. If you want to subscribe to other components you have to add them manually. The reason for the split is the build method, not the package kind, and the component list in the README makes that explicit. The tur component is the main one and contains almost all the packages. tur-on-device contains packages that cannot be cross-compiling, and it uses Termux-Docker to simulate a Termux-like environment, running under a self-hosted arm environment and a GitHub Actions provided x86 environment. Not every package is able to compile under it, which is the honest limit of that approach. tur-continuous contains packages that cost lots of time to compile, for example chromium-based applications, which is a separate problem from cross-compilation: these can be compiled, just not quickly. tur-hacking contains some hacking tools, and tur-multilib is marked as work in progress, containing some packages that provide a multilib environment. The repository root confirms the layout, with directories named tur/, tur-on-device/, tur-continuous/, tur-hacking/, tur-multilib/ and tur-disabled/, the last being where packages that have been withdrawn live.

A PyPI index for wheels that cannot be built on the phone

Not everything in TUR is a deb file, and the Python side has its own route. TUR also hosts a PyPI index and contains some prebuilt Python packages.

python -m pip install some_packages --extra-index-url https://termux-user-repository.github.io/pypi/

The README also explains how to make that permanent by adding the index to your pip configuration file at ~/.config/pip/pip.conf.

[install]
extra-index-url = https://termux-user-repository.github.io/pypi/

That is the practical part of the design. A wheel for a normal Python distribution is built for a specific interpreter ABI and platform, and an Android device running Termux's Python has a different platform tag, so the wheels on PyPI proper do not install. A separate index with wheels built for that environment solves it, and the extra-index-url mechanism lets you add it without replacing PyPI. The Python ecosystem on Termux is where the compilation problem bites hardest, because a large part of the scientific and tooling stack is distributed as source distributions that build on install. The companion repository pypi-wheel-builder contains the scripts to build and publish wheels to a custom PyPI index, and a separate pypi repository hosts the index pages for Termux and Android. So the Python support is not an accident of the main repository. It is a separate build and publish pipeline with its own repositories.

Adding a package: tur/ directory, build-package.sh and the four architectures

The build system is Termux's own, and the README is explicit that TUR uses the same building scripts as Termux does, so all the building mechanism is the same. Setting up the environment has two methods. The conventional one is to clone this repository, change directory, and execute ./setup-environment.sh, which will fetch the Termux package building scripts from the termux/termux-packages repository, and then follow the official Termux build environment guide. The second method is a dev container, either through the Visual Studio Code Dev Containers command on a local machine with Docker, or through GitHub Codespaces from the green code button on the repository page. Adding a package itself is a directory and a script.

TERMUX_INSTALL_DEPS=true ./build-package.sh -a <arch> <package-name>

The directory is tur/<your-package-name>, and the README is emphatic about one thing, that it must not be packages/<your-package-name>. The arch argument accepts aarch64, arm, i686 and x86_64. There is one flag specific to building on a phone. TERMUX_NO_CLEAN=true should be needed when building on an Android device, presumably because the clean step is the expensive part you want to skip when every build is on the target device. The build output structure is the standard Termux one, with the source tree ending up under ~/.termux-build/<package-name>/src, which is where the patching workflow starts.

Patching a source that needs a change to build

Some packages do not build unmodified, and the README describes a patch workflow that uses git rather than a patch file format from scratch. After running ./build-package.sh, you enter ~/.termux-build/<package-name>/src with VS Code's Open Folder command or with cd in a terminal. If git is not set up in that directory, you initialise it.

git init .
git commit -a -m "first commit"

You then modify the files that need patching and produce a patch.

git diff <path-to-modified-file> > <path-to-tur-repo>/tur/<package-name>/<any-name>.patch

And you re-run ./build-package.sh afterwards. The mechanism is a plain git diff, which is worth noting for a few reasons. Because the diff is produced against an initial commit of the extracted source, the patch applies to the upstream version of that file, which means the patch breaks when the upstream package is updated to a new version. There is no version pinning visible in the workflow described. The patch file lands inside the package's own directory in the TUR repository, which is the right place for it, since the build scripts pick up patches from the package directory the same way Termux does for its own packages. The sample/ directory in the repository shows the expected shape, with a sample/build.sh and a sample/sample-sub.subpackage.sh for anyone who wants to see a template before writing one.

The wider set of repositories around the package repo

TUR is more than one repository, and the README lists the others with what each one does. electron-tur-builder contains scripts to build a specific version of Electron and release the pre-built binaries to a GitHub release, and it provides an APT component called tur-electron. That is the chromium-based application case handled outside the normal build path. The dists repository contains scripts to publish the APT repository, hosts the GitHub Pages, and holds the deb files in its releases. That is where the actual repository artefacts live. Then there is the history. termux-docker is marked archived and is forked from termux/termux-docker, because the original contains binaries and libraries targeting API 28 while the fork contains ones targeting API 24, and it has been replaced with ndk-multilib-native-stubs, which directs clang to link to an API level 24 libc.so stub. The ndk-toolchain-gcc-9, 10, 11 and 12 repositories contain build scripts for building an NDK toolchain with GCC rather than LLVM. And tur-on-device is also marked archived, with the note that it has been merged into TUR. Two archived entries in a list of active ones is a useful signal. It tells you the project reorganises rather than accumulates, and that the on-device build path that once had its own repository is now a component inside the main one. The repository root also holds repo.json, big-pkgs.list, common-files/, continuous-build-wrapper.sh and TODO-zh-cn.md, the last being a Chinese translation of the TODO file that the README points to for more information about possible future components.

Editorial conclusion

Adopt tur if you run Termux on Android and need a package the official repository does not carry, or a Python wheel built for the Termux environment, and you would rather install a deb than compile on the device. Do not adopt it as a substitute for the official Termux repository, since TUR is explicitly a place for packages that could not be part of the official repo. Before you rely on it, check which components you have subscribed beyond the default tur, tur-on-device and tur-continuous, and pin your patches against the upstream version you built, since the git diff workflow described in the README has to be regenerated when the upstream package changes.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. termux-user-repository/tur on GitHub