Создание собственного репозитория пакетов Debian/Ubuntu в Termux с использованием apt-repo и автоматическим построением CI‑pipeline на GitHub Actions

Termux — удобная среда для работы с пакетами и сборки утилит прямо на Android. Если вам требуется не просто «поставить пакет», а построить собственный репозиторий Debian/Ubuntu и затем использовать его через APT в Termux (или на других системах), то связка apt-repo + аккуратная упаковка метаданных + CI‑pipeline на GitHub Actions закрывает большинство практических задач: от локальных экспериментов до регулярной публикации версий.

Ниже — практический сценарий: как подготовить репозиторий, собрать структуру дистрибутивов, сгенерировать Release/InRelease и подписи, а также организовать автоматизацию публикации при пушах в ваш репозиторий.

Что получится в итоге

Текущий Termux будет использоваться как среда сборки/упаковки .deb (при необходимости).
Вы создадите локальный APT‑репозиторий, совместимый по структуре с Debian/Ubuntu.
Сборка и публикация пакетов будут выполняться автоматически через GitHub Actions.
Пользователь сможет подключить ваш репозиторий командой в стиле APT (в пределах вашей сети/инфраструктуры).

Требования и допущения

У вас есть доступ к GitHub и репозиторию исходников.
Вы умеете создавать .deb (или берете готовый .deb и упаковываете в репозиторий).
Для публикации потребуется HTTP‑доступ к папке репозитория (например, GitHub Pages, облачное хранилище с выдачей по HTTP, внутренний web‑сервер в локальной сети и т. п.).
При необходимости подписи используются GPG‑ключи (лучше отдельный ключ под репозиторий).

Термины: компоненты APT‑репозитория

Минимально APT ожидает:

pool/ — реальные пакеты .deb.
dists/<suite>/ — метаданные (Release/InRelease и файлы индексов).
и базу для индексов (Packages, Packages.gz, Sources — в зависимости от сценария).
подпись (опционально, но желательно): InRelease/Release.gpg.

Шаг 1. Подготовка окружения в Termux

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

pkg update
pkg install -y git gnupg proot tar curl

Для работы с Debian/Ubuntu упаковкой и генерацией индексов вам понадобится apt-repo. В Termux обычно проще всего использовать путь через deb‑инфраструктуру/сборку или получить apt‑repo как часть инструментария (если доступно как пакет). Если apt-repo недоступен напрямую, рассмотрите сборку/установку из исходников, но в рамках статьи предполагаем, что он доступен в вашей среде.

Проверьте наличие:

command -v apt-repo || echo "apt-repo не найден в PATH"

Шаг 2. Создание структуры репозитория

Схема ниже — распространенная и удобная для CI. Выберите:

suite: например stable или testing
arch: например all или amd64 (для Termux чаще встречаются cross-сценарии, но структура APT общая)

Создадим директории:

export REPO_ROOT="$HOME/my-apt-repo"
export SUITE="stable"
export COMPONENT="main"
export ARCH="all"

mkdir -p "$REPO_ROOT/pool/${COMPONENT}/"
mkdir -p "$REPO_ROOT/dists/$SUITE/$COMPONENT/binary-$ARCH/"

Скопируйте в pool ваш(и) .deb. Например:

# Пример: разместить один пакет в pool
# pool обычно хранит .deb по подсказкам Debian, но для простоты можно начать с flat-структуры.
cp /path/to/your-package_1.0.0_all.deb "$REPO_ROOT/pool/${COMPONENT}/"

Шаг 3. Генерация индексов через apt-repo

Далее нужно сгенерировать индекс Packages. Принцип: apt-repo читает pool и пишет метаданные в dists/. Точные параметры зависят от версии apt-repo, поэтому ниже — типовой шаблон. Если ваш apt-repo требует иные флаги, адаптируйте под справку apt-repo --help.

Базовый вызов (шаблон):

# Шаблон: создаём индексы пакетов
apt-repo 
  --root "$REPO_ROOT" 
  --suite "$SUITE" 
  --component "$COMPONENT" 
  --arch "$ARCH"

После выполнения проверьте наличие файлов индекса:

find "$REPO_ROOT/dists/$SUITE" -maxdepth 5 -type f | sort

Шаг 4. Release и подписи (рекомендуется)

APT может ожидать Release‑файл. В некоторых реализациях apt-repo генерирует Release автоматически; в других — требуется отдельный этап. Уточните по вашим артефактам.

Проверка:

ls -la "$REPO_ROOT/dists/$SUITE"

Если Release/InRelease отсутствуют, вы можете добавить этап генерации и подписи через GPG (конкретные команды зависят от того, что уже подготовлено). Практический подход:

Сгенерировать Release (например, используя подходящие инструменты из Debian пакетов, либо используя возможности apt-repo).
Подписать Release.gpg.

Пример с использованием GPG как общий шаблон (ваши файлы и имена могут отличаться):

export GPG_KEY_ID="YOUR_KEY_ID"
gpg --batch --yes --local-user "$GPG_KEY_ID" 
  -abs -o "$REPO_ROOT/dists/$SUITE/Release.gpg" 
  "$REPO_ROOT/dists/$SUITE/Release"

Если вы планируете использовать подпись в APT, храните приватный ключ только в CI (секреты GitHub Actions), а в Termux — используйте локально для тестов.

Шаг 5. Подключение репозитория в APT

На машине, где вы хотите установить пакеты из вашего репозитория, нужно добавить строку в sources.list (или sources.list.d/).

Пример формата (в вашем случае URL зависит от способа публикации):

deb [arch=all] http://your-host.example.com/apt stable main

Если подпись используется, добавьте публичный ключ в trust-store. В Debian/Ubuntu это обычно делают через /etc/apt/trusted.gpg.d/ или signed-by в источнике. Конкретика зависит от вашей целевой ОС и политики безопасности.

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

Шаг 6. Публикация через HTTP

Apt репозиторий должен быть доступен по HTTP по URL вида:

http://host/apt/dists/...
http://host/apt/pool/...

Типовые варианты:

Внутренний web‑сервер в локальной сети (простая схема для команды).
Облачное хранилище с включенной раздачей по HTTP.
Статическая публикация (например, через GitHub Pages) — если вам подходит схема хостинга.

В этом примере предположим, что вы публикуете папку репозитория как статические файлы (в GitHub Pages или в ветку, доступную по HTTP).

Шаг 7. CI‑pipeline на GitHub Actions: автоматическая сборка и публикация

Идея CI: при каждом пуше в ветку (например, main) Actions:

Собирает/проверяет .deb (или использует уже готовые артефакты, если вы храните их в репозитории).
Собирает структуру репозитория.
Генерирует индексы (apt-repo) и Release/подписи (если настроено).
Публикует результат в HTTP‑доступное место (ветка gh-pages, artifact storage или любой приемлемый хостинг).

Пример .github/workflows/ci.yml (шаблон). Обратите внимание: команды и способы сборки .deb подстраиваются под ваш проект.

name: Build and Publish APT Repo

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install tools
        run: |
          sudo apt-get update
          sudo apt-get install -y gnupg dpkg-dev
          # apt-repo установить, если он доступен в вашем окружении,
          # либо собрать/доставить из вашего репозитория.
          # sudo apt-get install -y apt-repo || true

      - name: Prepare repo structure
        run: |
          export REPO_ROOT="${{ github.workspace }}/repo"
          export SUITE="stable"
          export COMPONENT="main"
          export ARCH="all"

          mkdir -p "$REPO_ROOT/pool/${COMPONENT}/"
          mkdir -p "$REPO_ROOT/dists/$SUITE/${COMPONENT}/binary-$ARCH/"

          echo "REPO_ROOT=$REPO_ROOT" >> $GITHUB_ENV

      - name: Build .deb (example)
        run: |
          # Замените на реальный процесс сборки вашего пакета
          # Например: dpkg-buildpackage / debuild / sbuild и т.д.
          #
          # В результате должны появиться .deb в директории, например dist/
          mkdir -p dist
          # cp -v path/to/your-package_.deb dist/
          echo "Place your .deb into dist/"

          cp -v dist/*.deb "${{ env.REPO_ROOT }}/pool/main/" || true
          
      - name: Generate apt indexes (apt-repo)
        run: |
          # Шаблон: адаптируйте под вашу версию apt-repo
          apt-repo 
            --root "${{ env.REPO_ROOT }}" 
            --suite "stable" 
            --component "main" 
            --arch "all" || true

      - name: Sign Release (optional)
        env:
          GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
          GPG_KEY_ID: ${{ secrets.GPG_KEY_ID }}
        run: |
          if [ -n "${GPG_PRIVATE_KEY}" ]; then
            echo "$GPG_PRIVATE_KEY" | gpg --batch --import
            # Примерный шаблон:
            gpg --batch --yes --local-user "$GPG_KEY_ID" 
              -abs -o "${{ env.REPO_ROOT }}/dists/stable/Release.gpg" 
              "${{ env.REPO_ROOT }}/dists/stable/Release" || true
          else
            echo "No GPG_PRIVATE_KEY provided. Skipping signing."
          fi

      - name: Publish (example to gh-pages)
        env:
          PUBLISH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}
        run: |
          # Публикация зависит от вашего hosting-плана.
          # Ниже — распространённая схема: пуш в gh-pages.
          #
          # Примерный каркас:
          # git clone --branch gh-pages https://x-access-token:${PUBLISH_TOKEN}@github.com//.git gh-pages
          # Copy repo/ contents into gh-pages/apt/
          # Commit and push

          echo "Implement publication steps according to your hosting choice."

Важно: в реальном проекте замените блоки Build .deb и Publish на конкретные команды под ваш пакет и способ раздачи (Pages, ветка, внешний сервер и т. д.).

Шаг 8. Управление версиями и воспроизводимость

Чтобы APT корректно обновлял пакеты, следите за:

Версией пакета в control/ changelog (и тэгами релиза при необходимости).
Стабильностью структуры dists/ (suite/component/arch не меняйте произвольно).
Генерацией индексов после каждого изменения pool.
Если вы подписываете Release — обновляйте подпись вместе с Release.

В CI можно добавлять проверку, что .deb существуют и индекс собран.

Шаг 9. Практический чеклист качества

В репозитории есть pool/ и dists/ нужного suite.
Сгенерированы Packages.gz (или хотя бы Packages) и файл Release содержит ссылки на них.
Если используется подпись: Release.gpg или InRelease присутствуют и APT это принимает.
URL репозитория в клиентах APT соответствует структуре (путь до dists/ должен быть правильным).
HTTP‑сервер отдает файлы без искажений (правильные заголовки редко критичны, но кеширование может мешать — учитывайте это).

Заключение

Создание собственного APT‑репозитория Debian/Ubuntu в Termux с использованием apt-repo — это реально и практично: вы получаете управляемую систему дистрибуции .deb‑пакетов и возможность полностью автоматизировать сборку и публикацию через CI‑pipeline на GitHub Actions. Ключ к успеху — корректная структура pool/ и dists/, регулярная генерация индексов и (по возможности) подпись Release.

Хотите быстрее и надежнее внедрить это в свой проект (с учетом вашей структуры пакетов, подписи и выбранного способа публикации)? Обращайтесь в РыбинскЛАБ — поможем спроектировать репозиторий и настроить CI под ваши требования.