termux-packages: the build system behind Termux's apt repositories

What termux-packages actually is, and who should care

The README opens with a one-line definition: this project contains scripts and patches to build packages for the Termux Android application. That sentence separates two audiences that are easy to confuse. Anyone running apt or pkg inside Termux is consuming the output of this repository. Nobody running apt or pkg needs to clone it. The README itself redirects that audience to a separate Package Management wiki page, which also covers how to fix repository is under maintenance or down errors.

The people this repository is for are package maintainers. If you want a library that is not in the Termux repositories to become installable with pkg install, the work happens here: a build recipe, a set of patches against upstream source, and a pull request. The top-level layout reflects that. packages/, root-packages/, x11-packages/ and disabled-packages/ are separate trees for different classes of software, and repo.json plus the scripts/ directory hold the metadata and tooling that turn recipes into repository indexes.

How a package recipe becomes an Android binary

The build model is patch-and-cross-compile. Each package lives in its own directory under one of the trees, and the repository ships a sample/ directory with the canonical file names: build.sh, a .subpackage.sh variant, and a .alternatives file. The build.sh is the recipe. It declares where the upstream source comes from and how to configure and compile it, and the surrounding patches adapt that source to Android's libc, filesystem layout and missing pieces.

That adaptation is not incidental. The ndk-patches/ directory exists because the Android NDK's headers and behaviour differ from a normal Linux target, and the patches there are applied so that ordinary Unix software can be built at all. This is the part that makes the project more than a wrapper around a compiler: a large share of the value is accumulated knowledge about which upstream projects need which adjustments.

Three scripts sit at the root for driving builds. build-package.sh builds one package, build-all.sh walks the trees, and clean.sh resets state. The dependency graph is expressed in the recipes themselves, so a package that needs a library built first will pull that library into the build rather than relying on a system copy.

Building a package: the workflow the repository documents

The README does not walk through a local build; it points contributors at CONTRIBUTING.md and the Developer's Wiki. The Docker image referenced in the README badge, termux/package-builder on Docker Hub, is the environment the project publishes for building, which avoids reproducing the toolchain by hand.

A first real use is to build an existing recipe rather than write a new one. The repository root contains build-package.sh, and the sample/ directory contains build.sh, which is the template a new package directory is based on. The README does not print the invocation itself, so the script name at the repository root is the only part of the command you can take directly from the files listed.

What you should see, once a recipe is in place, is the source being fetched, patched and compiled, with the resulting .deb artefacts written to the output directory the script uses. The README does not document rollback or a dry-run mode, so treat the first invocation as a real build and inspect the output rather than assuming a preview step exists.

Where termux-packages is the wrong tool

The clearest wrong use is treating it as an installation method. It builds packages; it does not install them on a device. The README's own framing, scripts and patches to build packages, rules out the common search intent of installing packages on a phone. That task belongs to the Termux app and the Package Management wiki page, and the README explicitly links there.

A second constraint is scope. The trees are split into packages/, root-packages/ and x11-packages/, and there is a disabled-packages/ tree, which tells you some software is deliberately not built. A package can be excluded because it does not work under Android's constraints, because it is unmaintained upstream, or because it conflicts with how Termux runs. If your target is in disabled-packages/, the repository is telling you something rather than offering a workaround.

A third is that cross-compilation patches are maintenance debt. Every patch against upstream source has to be rebased when upstream changes. That is the cost of the approach, and it is why the project publishes bootstrap archives on a roughly weekly cadence, with the most recent listed as bootstrap-2026.08.23-r1+apt.android-7. A recipe that builds today can stop building after an upstream release, and nothing in the README promises otherwise.

The alternative: use a distribution's own Android packages

The realistic alternative for most people is not another build system but a different distribution of prebuilt Android userspace. A Linux distribution that ships its own Android or ARM packages, or a proot-based distribution running inside Termux, gives you binaries someone else already compiled and tested. The difference in approach is who owns the patches. With termux-packages, the patch set is maintained here and applied at build time, and the output is native Android binaries that run without a compatibility layer. With a proot distribution, the patches live in that distribution's packaging, and the binaries run under emulation of a filesystem layout, which changes performance and path assumptions.

If your goal is to run a specific tool, that distinction decides the choice. Native builds avoid the proot overhead; proot builds avoid the wait for someone to add a recipe here. Neither is universally better, and they fail in different ways.

Maintenance cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-23. The release list shows bootstrap archives published on 2026-08-09, 2026-08-16 and 2026-08-23, a weekly rhythm. That cadence is about the bootstrap artefacts, not about any individual package being current, so do not read it as a guarantee that a given recipe is healthy.

Licensing needs care. The repository's licence is reported as NOASSERTION, and a LICENSE.md file is present at the top level. That file governs the scripts and patches in this repository. It does not govern the upstream source your recipe downloads, which carries its own licence, and it does not govern the compiled binaries you produce. If you plan to redistribute what you build, check the upstream project's licence separately.

The upgrade cost is concentrated in the patches. When you maintain a recipe, an upstream release can invalidate a patch, and the fix is manual. CONTRIBUTING.md and the Developer's Wiki are where the project documents its expectations for that work; the README gives no other guidance on patch maintenance.

Editorial conclusion

Adopt termux-packages if you maintain or want to contribute a package to the Termux apt repositories, or if you need to cross-compile a specific library for Android with the same patch conventions. Do not adopt it if you only want to install software on your phone: the README sends you to the Termux app and the Package Management wiki page instead. Before committing time, read CONTRIBUTING.md and the Developer's Wiki, then check whether the package you care about already exists under packages/ or x11-packages/, and confirm the licence of the upstream source you intend to build, since this repository's own LICENSE.md is not the licence of what you compile with it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes