Rejected from termux-packages and TUR? How to Publish Your Tool to Termux Users Anyway

You spent weeks building a CLI tool. It runs perfectly on your phone in Termux. You open a pull request to termux-packages, and a few days later it's closed.

So you try TUR. Same story: stalled, or declined.

Now what? Do you tell your users to keep doing this?

git clone https://github.com/you/your-tool
cd your-tool
# install dependencies
# hope the build works on their device

Most people never get past that. If this is you, this guide is for you.

First: a rejection doesn't mean your tool is bad

Official and curated repositories have to be selective. They're maintained by a small group of people who have to keep every package building for every Termux user, so they usually care about things like:

• Scope: is the software widely used enough for a core repository?
• Maintenance: will someone keep it working long term?
• Build reproducibility: does it build cleanly inside the Termux build environment?

A niche tool, a young project, an experimental project, or a tool maintained by one person can fail those checks and still be genuinely useful to a lot of people. The official repositories are great, and nothing here is meant to replace them. But your tool still deserves a way to reach users.

The option: publish to Termux App Store

Termux App Store is a community-driven package manager for Termux (a TUI and a CLI). Anyone can submit a package through a pull request, and users install it with one command:

termux-app-store install your-tool

Two things to know up front:

• It's an independent community project, not affiliated with the official Termux project.
• Packages are installed with termux-app-store, not with plain pkg install. In exchange, you get a much lower barrier to publishing.

Your package is one file, packages/your-tool/build.sh, and you don't have to write it by hand.

Step-by-step: publish your tool

Step 0: What you need

• A public GitHub repository for your tool
• A tagged release (for example v1.0.0) or at least a stable source tarball URL
• A license
• Termux with git and python:

pkg install git python

Step 1: Clone the repository

git clone https://github.com/djunekz/termux-app-store
cd termux-app-store

(Better: fork it on GitHub first and clone your fork, since you'll open a pull request later.)

Step 2: Generate your build.sh

The easiest way is the scaffold wizard. Give it your repo URL and it pre-fills as much as it can:

python pkg-scaffold.py --from https://github.com/you/your-tool

Here's what it does for you:

1. Reads your GitHub repo: description, license, and latest release or tag.
2. Asks for the basics: package name, description, homepage, license, maintainer, version.
3. Computes the SHA256 by downloading your source tarball, so you don't have to.
4. Detects how your project builds: Python script, pip package, shell script, npm, Cargo (Rust), Go, Makefile, CMake, Ruby, Perl, Lua, PHP, or "other".
5. Asks for your entrypoint (for script-type tools) and any extra dependencies.
6. Shows a review screen, then writes packages/your-tool/build.sh.

Prefer a different route? Either of these also works:

./termux-build init https://github.com/you/your-tool   # auto-create from a GitHub URL
./termux-build create your-tool                         # blank template

Step 3: Read what it generated

Open packages/your-tool/build.sh. The header looks like this:

TERMUX_PKG_HOMEPAGE="https://github.com/you/your-tool"
TERMUX_PKG_DESCRIPTION="One-line description"
TERMUX_PKG_LICENSE="MIT"
TERMUX_PKG_MAINTAINER="@you"
TERMUX_PKG_VERSION="1.0.0"
TERMUX_PKG_SRCURL="https://github.com/you/your-tool/archive/refs/tags/v1.0.0.tar.gz"
TERMUX_PKG_SHA256="<64-character checksum>"

Quick rules that save you a review round:

• Package name: lowercase letters, numbers and hyphens only (my-tool, not My Tool).
• Version: starts with a digit, no v prefix (1.0.0, not v1.0.0).
• Pin to a release or tag, not a moving branch. If your repo has no release or tag, the wizard falls back to a specific commit and warns you. A floating branch would need re-pinning later, so it's best to tag a release first.
• Check the install step. For tools that need a custom setup, review the termux_step_make_install() function it generated and edit it if needed.

Step 4: Validate before you submit

./termux-build lint your-tool       # check the build script
./termux-build check-pr your-tool   # check PR readiness
./termux-build doctor               # diagnose your environment if something fails

Stuck on an error? These can help:

./termux-build suggest your-tool    # improvement suggestions
./termux-build explain your-tool    # detailed explanation of the package
./termux-build guide                # contribution guide

Note that termux-build only reads and validates. It never uploads anything for you.

Step 5: Open a pull request

git checkout -b add-your-tool
git add packages/your-tool
git commit -m "Add your-tool 1.0.0"
git push origin add-your-tool

Then open a pull request on GitHub. Reviewers look at your build.sh, so a clean lint and a clear description make a big difference.

For the latest rules, check HOW_TO_UPLOAD.md and CONTRIBUTING.md in the repository, since requirements can change.

Step 6: Tell people how to install it

Once your package is merged, put this in your own README:

## Install on Termux

```bash
pkg install python
pip install termux-app-store
termux-app-store install your-tool
```

If a user prefers building from source instead of a pre-built binary, they can run termux-app-store fix-install your-tool.

Pre-submission checklist

• [ ] Public repo with a clear license
• [ ] Tagged release and a stable source URL
• [ ] Correct SHA256 (not skipped)
• [ ] Package name: lowercase, hyphens only
• [ ] Version without a v prefix
• [ ] Dependencies declared (TERMUX_PKG_DEPENDS)
• [ ] Tested in Termux on at least one architecture (most phones are aarch64)
• [ ] ./termux-build lint passes
• [ ] ./termux-build check-pr passes
• [ ] README tells users how to install it

Common problems

"The wizard couldn't fetch my metadata."
It uses the GitHub API. If you're offline or rate-limited, it will tell you and let you fill the fields in manually.

"My project has no release or tag."
Create a tag on GitHub (git tag v1.0.0 && git push --tags), then run the wizard again.

"It builds on my phone but fails in review."
Run ./termux-build doctor and check dependencies and paths. Termux uses $PREFIX (/data/data/com.termux/files/usr), not /usr.

"Where does my tool end up?"
In the packages/ folder of the repository, where users can browse it in the TUI or find it with termux-app-store search.

Why this is worth doing

A tool nobody can install easily is a tool nobody uses. Turning "clone, install deps, compile, debug" into a single install command is one of the best things you can do for your users, and it takes minutes, not days.

If you were rejected elsewhere, don't give up on your tool. Package it, validate it, and ship it.

Links

• Termux App Store: https://github.com/djunekz/termux-app-store
• Website: https://termux-app-store.pages.dev/
• PyPI: https://pypi.org/project/termux-app-store/

Disclosure: I maintain Termux App Store, which is an independent project and not affiliated with the official Termux project.

Have you been rejected from an official repo, or got a tool you want packaged? Share it in the comments and I'll help you with your build.sh. 👇