Создание и управление собственным репозиторием пакетов Termux: кастомные скрипты сборки и подписи

Termux — это не только удобная среда выполнения в Android, но и полноценная платформа для сборки и распространения пакетов. Когда вы хотите поддерживать собственные библиотеки, утилиты или сборки с нужными флагами, возникает задача: создать и управлять собственным репозиторием пакетов Termux.

В этом материале мы рассмотрим практический подход к созданию репозитория: от структуры и кастомных скриптов сборки до публикации и подписи артефактов. Фокус — на легальных и безопасных механизмах, которые позволяют вам контролировать состав пакетов и их обновления.

Общее понимание: что такое репозиторий Termux

Репозиторий в контексте Termux — это набор пакетов (архивов) и метаданных, которые позволяют клиенту (pkg/termux) понимать, какие версии доступны, и проверять целостность/подлинность. Как правило, используются:

архивы пакетов и/или их содержимое в согласованном формате;
метаданные (индексы), описывающие пакеты и версии;
подписи и механизмы проверки, чтобы клиент доверял репозиторию.

Важная цель — не просто “положить файлы в веб-страницу”, а построить процесс, в котором сборка воспроизводима, обновления управляемы, а доверие обеспечивается подписями.

Подготовка окружения

Для работы удобно использовать Termux на вашем устройстве. Однако критически важно подготовить среду под сборку: компиляторы, зависимости и инструменты упаковки.

На практике вы будете использовать стандартные механизмы Termux: инструменты сборки (часть инфраструктуры находится в репозиториях Termux), инфраструктуру для конфигурации и процесс сборки пакетов из исходников. В рамках вашей задачи вам нужен еще один слой: скрипты и репозиторий.

Рекомендуемая базовая настройка включает обновление системных пакетов:

pkg update -y
pkg upgrade -y

Далее устанавливают утилиты, которые почти всегда нужны при подготовке релизов, индексов и подписи:

pkg install -y git curl gnupg

Если вы планируете сборку из исходников и генерацию пакетов, убедитесь, что у вас есть инструментальная цепочка (на типовых сборках это достигается через стандартные пакеты Termux и/или зависимости, необходимые вашим проектам).

Структура собственного репозитория

Чтобы репозиторий было удобно сопровождать, заведите понятную структуру каталогов на сервере или локально.

Один из практичных вариантов:

repo/
  dists/
    stable/
      main/
        index
        Packages
        Release
        Release.gpg
  pool/
    custom/
      <package-name>/
        <version>/
          <package-file>

Точные имена метаданных зависят от того, как именно вы настроите публикацию и какой формат индексирования будете использовать. Общая идея неизменна:

pool хранит бинарные артефакты;
dists содержит индексирующие файлы;
Release и Release.gpg обеспечивают сигнатуры для проверки.

Если вы планируете разворачивать репозиторий локально (например, в вашей локальной сети), можно поднять HTTP-сервер и раздавать каталог репозитория, не прибегая к обходу ограничений.

Кастомные скрипты сборки: принцип “один пакет — один процесс сборки”

Кастомные сборочные скрипты нужны, чтобы вы:

фиксировали версии исходников;
управляли флагами компилятора;
повторяемо получали артефакты;
автоматически формировали пакет и его метаданные;
в конце выполняли подпись.

Практика: делайте “pipeline” из шагов. Например, создайте структуру проекта сборки:

build-system/
  scripts/
    fetch_sources.sh
    build_package.sh
    make_index.sh
    sign_release.sh
  config/
    packages.yml
  out/
    staging/
    dist/

Типовой набор переменных и конфигурации должен включать:

название пакета;
версию;
URL исходников (или локальный путь);
какие зависимости нужны;
команду/флаги компиляции;
какой ключ подписи использовать.

Пример: шаблон сборочного процесса

Ниже — пример высокоуровневого “скелета” скрипта. Он не привязан к конкретному upstream-формату пакета, а демонстрирует, как организовать сборку, упаковку и подготовку к индексации/подписи.

# build-system/scripts/build_package.sh
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

PACKAGE_NAME="${1:?package name}"
VERSION="${2:?version}"
BUILD_DIR="build/${PACKAGE_NAME}-${VERSION}"
STAGING_DIR="out/staging/${PACKAGE_NAME}/${VERSION}"

rm -rf "$BUILD_DIR" "$STAGING_DIR"
mkdir -p "$BUILD_DIR" "$STAGING_DIR"

echo "[] Fetching sources..."
# ./scripts/fetch_sources.sh "$PACKAGE_NAME" "$VERSION" "$BUILD_DIR"

echo "[] Building..."
# Пример: выстраивание toolchain/настроек под Termux и сборка
# export CFLAGS="..."
# export LDFLAGS="..."
# make -j$(nproc) && make install DESTDIR="$STAGING_DIR"

echo "[] Packaging..."
# Здесь формируется архив пакета в согласованном формате вашего репозитория
# В зависимости от выбранного формата — tar/zip/специальный пакет.

echo "[] Done. Output: $STAGING_DIR"

Если вы собираете несколько пакетов, удобно управлять ими через единый YAML/конфиг и итерацию по списку. Например:

# build-system/scripts/build_all.sh
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

CONFIG_FILE="config/packages.yml"

# Пример упрощён: в реальном проекте распарсите YAML через yq/python
# и подставляйте PACKAGE_NAME/VERSION.
# for each package:
#   ./scripts/build_package.sh "name" "version"

Создание метаданных и индекса

Репозиторий должен уметь отвечать на вопросы “какие пакеты доступны” и “какая версия является актуальной”. Для этого создают индексные файлы.

Если вы используете схему с Release/Packages и подписью, сценарий обычно выглядит так:

собрать список артефактов из pool;
сгенерировать файл Packages (или аналогичный);
сгенерировать Release (с хешами и версиями);
подписать Release ключом.

Пример скрипта индексации (концептуально):

# build-system/scripts/make_index.sh
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

REPO_ROOT="${1:?repo root}"
DIST="stable"
COMPONENT="main"

POOL_DIR="$REPO_ROOT/pool/custom"
DISTS_DIR="$REPO_ROOT/dists/$DIST/$COMPONENT"

mkdir -p "$DISTS_DIR"

echo "[] Generating Packages index..."
# Сканирование pool/custom и сбор информации о пакетах.
# Вы можете сформировать Packages по вашему формату:
# - имя пакета
# - версия
# - размер
# - хеш
# - зависимости (если вы их поддерживаете)

# Пример заглушки:
cat <<EOF > "$DISTS_DIR/Packages"
# Packages index (generated)
EOF

echo "[] Generating Release file..."
# Release должен содержать хеши Packages и других файлов.
cat <<EOF > "$DISTS_DIR/Release"
# Release (generated)
EOF

echo "[] Index created at: $DISTS_DIR"

Подписи: доверие к репозиторию

Подпись — это ключевой элемент управления репозиторием. Она позволяет клиенту уверенно проверять, что метаданные действительно сформированы вами, а не подменены.

Обычно используют GPG-ключи. Сам процесс:

создать ключ (если у вас его нет);
поместить публичный ключ на стороне клиента (для доверия);
подписывать Release (или аналог метаданных);
следить за ротацией ключей и периодом действия.

Пример генерации ключа (подходит для тестовой/внутренней инфраструктуры):

gpg --full-generate-key

Затем подпись Release:

# build-system/scripts/sign_release.sh
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

REPO_ROOT="${1:?repo root}"
DIST="stable"
COMPONENT="main"

RELEASE_PATH="$REPO_ROOT/dists/$DIST/$COMPONENT/Release"
RELEASE_GPG_PATH="$REPO_ROOT/dists/$DIST/$COMPONENT/Release.gpg"

KEY_ID="${2:?gpg key id}"

echo "[] Signing Release..."
gpg --yes --armor --local-user "$KEY_ID" --output "$RELEASE_GPG_PATH" --detach-sign "$RELEASE_PATH"

echo "[] Signed: $RELEASE_GPG_PATH"

Важно: ключи и секретные материалы должны храниться безопасно. Не помещайте приватный ключ в репозиторий кода без необходимости, используйте парольную защиту и ограничение доступа.

Публикация репозитория: локальный HTTP (без обхода блокировок)

Для разработки и проверки репозитория удобно поднять локальный HTTP-сервер. Это полезно при тестировании обновлений на других устройствах в вашей локальной сети.

Пример на Termux (концептуально):

cd /path/to/repo
python -m http.server 8080

Если требуется, убедитесь, что устройство клиента сможет обратиться к вашему IP в локальной сети. При необходимости настройте firewall на стороне сервера (без каких-либо схем обхода блокировок — только корректная локальная доступность).

Добавление репозитория в Termux

На стороне Termux вы добавляете источник пакетов (репозиторий) в конфигурацию пакетов. В зависимости от версии клиентской инфраструктуры Termux и формата вашего репозитория, путь может отличаться.

Общий подход:

указать URL репозитория;
включить проверку подписи;
добавить публичный ключ в доверенные, если это требуется вашим форматом репозитория;
выполнить обновление индексов и установить пакет.

После добавления репозитория используйте команду обновления:

pkg update

Далее можно устанавливать пакет:

pkg install <package-name>

Если подписи настроены правильно, клиент должен подтверждать целостность и подлинность метаданных.

Автоматизация релизов: от “собрал” до “опубликовал”

Чтобы управление репозиторием было удобным, соберите релизный сценарий, который:

собирает один или несколько пакетов;
копирует артефакты в pool;
генерирует индексы;
подписывает Release;
поднимает/уведомляет об изменениях (если у вас есть CI/CD).

Сценарий можно оформить как одну команду, например:

# build-system/scripts/release.sh
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

REPO_ROOT="$1"
KEY_ID="$2"
DIST="stable"
COMPONENT="main"

# 1) build packages (у вас свои вызовы)
# ./scripts/build_all.sh

# 2) copy artifacts to $REPO_ROOT/pool/custom/...

# 3) make index
./scripts/make_index.sh "$REPO_ROOT"

# 4) sign release
./scripts/sign_release.sh "$REPO_ROOT" "$KEY_ID"

echo "[] Release pipeline finished."

Типовые ошибки и как их избежать

Клиент не доверяет репозиторию: проверьте, что публичный ключ добавлен, а подпись выполнена именно для того Release, который вы публикуете.
Обновления не видны: проверьте, что индексы пересоздаются после загрузки новых пакетов в pool и что URL корректен.
Несовпадение версий: следите за тем, чтобы имена файлов и версия в метаданных соответствовали друг другу.
Проблемы с воспроизводимостью: фиксируйте исходники (commit/tag), версию toolchain и фиксированные флаги компиляции.

Заключение

Создание собственного репозитория пакетов Termux — это процесс, который выгодно выстраивать как “конвейер”: кастомные скрипты сборки формируют артефакты, затем автоматически генерируются метаданные и выполняется подпись. Такой подход дает управляемые обновления, контроль состава пакетов и доверие со стороны клиентов.

Если вам нужна помощь с проектированием процесса сборки, структурой репозитория, настройкой индексов и подписи, а также с интеграцией в ваши рабочие сценарии — обращайтесь в РыбинскЛАБ. Мы поможем выстроить надежную инфраструктуру под ваши задачи.