Создание и управление собственными репозиториями пакетов (APT, pkg) в Termux: сборка, подпись и публикация

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

• публиковать версии пакетов контролируемым способом;
• централизованно обновлять зависимости;
• поддерживать откат и воспроизводимость;
• включать цифровую подпись, чтобы снизить риск подмены;
• ускорить установку на нескольких устройствах.

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

Важно про юридические и организационные аспекты

Вы публикуете только те пакеты и исходники, на которые имеете право распространять (лицензии, авторские права, внутренние политики). Цифровая подпись и проверка целостности не заменяют правовые аспекты: это вопрос доверия и безопасности поставки.

Статья ориентирована на законное и безопасное управление собственными пакетами.

Предварительные требования

• Linux-хост (можно и локально на ПК) или отдельная среда, где удобнее собирать .deb и обслуживать репозиторий.
• Ключ для подписи (GPG).
• Понимание структуры APT: Packages, индексы, Release.
• Доступ к веб-серверу или статическому хостингу (HTTP/HTTPS) для публикации.

На стороне Termux вы подключите репозиторий через sources.list и установите пакет командой apt install.

Термины: APT-репозиторий и pkg-данные

Termux из коробки использует APT и формирует установку из deb пакетов. Для собственных репозиториев вам важно подготовить как минимум APT-индексы:

• deb-пакеты (например, mypkg_1.0-1_all.deb);
• Packages (список пакетов для раздачи);
• Release (метаданные о репозитории и подпись).

Термин pkg в экосистеме Termux часто означает итоговую систему упаковки/метаданных, но для практической публикации через APT ключевой результат — корректная APT-структура и индексы.

Архитектура репозитория: базовая структура директорий

Рекомендуемая структура (условно):

repo-root/
  dists/
    stable/
      Release
      main/
        binary-amd64/   (опционально)
        binary-arm64/   (опционально)
        binary-arm/     (опционально)
  pool/
    stable/
      mypkg/ 
        mypkg_1.0-1_all.deb
  gpg/ (необязательно)

Как правило, вы упростите жизнь, если будете публиковать один “distribution” (например, stable) и один набор архитектур или только all (если пакеты не зависят от архитектуры).

Сборка .deb пакета для Termux

Сборка зависит от того, что именно вы упаковываете: готовые бинарники, скрипты или собираемый из исходников проект. Универсальный подход для APT — собрать .deb.

Пример типового набора файлов для deb:

• DEBIAN/control — метаданные пакета;
• файлы внутри usr/ или opt/ (в зависимости от того, как вы размещаете файлы);
• скрипты обслуживания (если нужно): preinst, postinst и т.д.;
• архивирование (через dpkg-deb или подобные инструменты).

Если вы используете чистую “ручную” сборку, базовая заготовка может выглядеть так:

# структура рабочей папки пакета
mkdir -p build/mypkg/usr/bin
mkdir -p build/mypkg/DEBIAN

# пример control
cat > build/mypkg/DEBIAN/control << 'EOF'
Package: mypkg
Version: 1.0-1
Architecture: all
Maintainer: You <you@example.com>
Description: My Termux package
EOF

# пример содержимого
cat > build/mypkg/usr/bin/mypkg-cli << 'EOF'
#!/data/data/com.termux/files/usr/bin/sh
echo "Hello from mypkg"
EOF
chmod +x build/mypkg/usr/bin/mypkg-cli

# сборка
dpkg-deb --build build/mypkg

Если у вас нативный код (C/C++), обычно требуется toolchain и сборка под среду Termux. На практике чаще используют готовые “recipes” и стандарты сборки, но принцип публикации одинаков: итог — корректный .deb.

Размещение .deb в pool

После сборки переместите пакет в pool. Например:

mkdir -p repo-root/pool/stable/mypkg
cp mypkg_1.0-1_all.deb repo-root/pool/stable/mypkg/

Папки в pool можно выбирать по соглашению (главное — потом корректно сгенерировать индексы).

Создание индексов APT: Packages.gz и Release

Далее нужно сгенерировать Packages и связать это с Release. Обычно используют apt-ftparchive из пакета apt-utils.

Пример для “stable” и одной секции main (подстроите под свои архитектуры и реальные пути):

mkdir -p repo-root/dists/stable/main/binary-all

apt-ftparchive packages \
  repo-root/pool/stable/ \
  --arch all \
  > repo-root/dists/stable/main/binary-all/Packages

gzip -kf repo-root/dists/stable/main/binary-all/Packages

Затем создайте файл Release:

cd repo-root

apt-ftparchive release \
  dists/stable \
  > dists/stable/Release

Если конфигурация сложнее (несколько секций/архитектур), можно писать конфиг для apt-ftparchive, но базовый путь остаётся тем же.

Цифровая подпись репозитория

Подпись делается GPG и позволяет клиенту (Termux/apt) доверять индексу. Рекомендуется:

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

Создание ключа (если его нет):

gpg --full-generate-key

Подпись Release обычно требует команды вида:

# пример: подпишем Release, чтобы получилось Release.gpg
gpg --armor --detach-sign \
  -o dists/stable/Release.gpg \
  dists/stable/Release

# иногда также создают InRelease
gpg --clearsign \
  -o dists/stable/InRelease \
  dists/stable/Release

Какие именно файлы нужны вашему клиенту, зависит от того, как Termux настроен на проверку. Часто достаточно Release.gpg, но самый совместимый вариант — иметь и InRelease, и/или оба формата.

Концепция: публикация на HTTP/HTTPS

После генерации индексов и подписи репозиторий должен быть доступен по URL. Обычно это простой веб-сервер, который отдает статику.

Пример запуска локально:

# в корне repo-root
python3 -m http.server 8080

Тогда репозиторий будет доступен по адресу вида:

http://<host>:8080/ с путями вроде:

• /dists/stable/Release
• /dists/stable/Release.gpg
• /dists/stable/main/binary-all/Packages.gz

Для внешней публикации используйте HTTPS и нормальную инфраструктуру; если делаете только локальный раздающий сервер для своей сети, это допустимо. VPN имеет смысл только для создания локальной сети в целях администрирования, а не для обхода ограничений.

Подключение репозитория в Termux

На устройстве Termux откройте список источников APT. В Termux это обычно файл:

/data/data/com.termux/files/usr/etc/apt/sources.list

Добавьте строку вида:

# пример (подставьте ваш URL)
# deb [trusted=yes] http://<host>:8080 stable main

deb http://<host>:8080 stable main

Если вы настроили подпись, не ставьте [trusted=yes] без необходимости — лучше использовать проверку. На практике для проверки ключей вы добавляете публичный ключ в доверенную область APT Termux (детали зависят от конкретной версии Termux/apt). Если требуется временная установка для отладки, [trusted=yes] можно использовать только как тестовую мера и затем убрать.

После добавления источника выполните обновление индексов:

pkg update
apt update

Установка пакета:

apt install mypkg

Проверка и устранение типичных проблем

1) apt не видит пакет

• Проверьте, что Packages.gz соответствует структуре и содержит нужный Package и Version.
• Убедитесь, что Release ссылается на правильные файлы (хэши генерируются при создании Release).
• Проверьте URL и доступность файлов через браузер или curl на стороне клиента.

2) Ошибка подписи

• Сверьте, что Release.gpg существует и корректно подписывает ваш Release.
• Убедитесь, что на клиенте Termux ключ доверен (конфигурация ключей APT).
• Не подменяйте индексы “после” подписания, иначе хэши и подписи разойдутся.

3) Проблемы с архитектурой

• Если пакет Architecture: all, то кладите индексы в блок binary-all.
• Если собираете под конкретную архитектуру (например, ARM), индексы должны быть отдельно для нужной архитектуры.

Практический цикл обновления версии пакета

При каждом изменении пакета:

1. пересоберите .deb с новой версией;
2. положите новый deb в pool (можно оставлять старые для “истории”, если это не мешает);
3. пересоберите Packages*;
4. пересоберите Release;
5. переподпишите Release;
6. перезапустите публикацию (если сервер кэширует — очистите кэши);
7. на Termux выполните apt update и установку/обновление.

# на стороне хоста репозитория
# после замены/добавления .deb
apt-ftparchive packages repo-root/pool/stable/ --arch all > repo-root/dists/stable/main/binary-all/Packages
gzip -kf repo-root/dists/stable/main/binary-all/Packages

cd repo-root
apt-ftparchive release dists/stable > dists/stable/Release

gpg --armor --detach-sign -o dists/stable/Release.gpg dists/stable/Release

gpg --clearsign -o dists/stable/InRelease dists/stable/Release

Безопасность поставки: что ещё можно усилить

• Используйте HTTPS, особенно при внешней публикации.
• Ограничьте доступ к серверу публикации (если это приватно).
• Держите приватный ключ подписи изолированным, а подпись делайте на отдельной машине.
• Следите за изменениями в apt/Termux, потому что механика доверия ключам и поддержка форматов индексов может отличаться.

Заключение

Создание собственного репозитория для Termux — это управляемый процесс: вы собираете .deb пакеты, размещаете их в pool, генерируете APT-индексы Packages, формируете Release, подписываете его GPG и публикуете структуру через HTTP/HTTPS. Затем вы подключаете репозиторий в Termux и устанавливаете пакеты через apt install с проверкой доверия.

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