Я собрал deb пакет со своей прогой, нужно как-то ее распространять. Мне нужно чтобы пользователь смог установить мою прогу одной командой apt install , может двумя, если нужно добавить репозиторий. Как мне это сделать?
Отслеживать
209 1 1 серебряный знак 15 15 бронзовых знаков
задан 11 июн 2020 в 15:15
Николай Николаевич Николай Николаевич
454 3 3 серебряных знака 17 17 бронзовых знаков
Смотрел aptly ?
12 июн 2020 в 13:40
Ну вот рекомендую. Он более навороченный, чем, reprepro и у него есть api. Даже Майкрософт им пользуется.
12 июн 2020 в 20:02
13 июн 2020 в 19:14
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
apt-get install reprepro gnupg2 mkdir /var/www/debian mkdir /var/www/debian/conf touch /var/www/debian/conf/distributions editor /var/www/debian/conf/distributions
Там пишем описание репозитория
Codename: stable Suite: stable Version: 1.x Origin: Nikolaich Label: Nikolaich Description: Nikolaich Stable Repository Architectures: amd64 Components: main SignWith: default DebIndices: Packages Release . .gz .bz2 DscIndices: Sources Release . .gz .bz2 Contents: . .gz .bz2
cd /var/www/debian gpg —gen-key gpg —armor —export > repokey.asc
Там будет айди ключа, типа 4607CAF2F88913A6 Его добавить в файл выше.
Изучение Git для новичков / #2 — Добавление файлов в репозиторий
SignWith: 4607CAF2F88913A6
Дальше создаем саму репу
cd /var/www/debian reprepro export reprepro createsymlinks
И заливаем пакет
reprepro —priority optional —section drivers includedeb stable /root/mysuper.deb
Потом настраиваем вэб-сервер, чтоб папка debian была доступна через http://example.com/debian/
Устанавливается в для клиентов в пару команд:
wget -O- http://example.com/debian/repokey.asc | apt-key add — echo «deb http://example.com/debian stable main» > /etc/apt/sources.list.d/myrepo.list apt update
Отслеживать
ответ дан 11 июн 2020 в 18:30
31.9k 3 3 золотых знака 26 26 серебряных знаков 56 56 бронзовых знаков
Есть проект aptly. Навороченная штука от Андрея Смирнова.
Умеет делать зеркала других реп, создавать свои репы, снапшоты. Можно работать как через CLI, так и через API.
На Хабре описан опыт использования.
P.S. Даже Майки используют для распространения собственных пакетов. Проверяется в 2 счёта: curl —silent http://packages.microsoft.com/repos/ms-teams/dists/stable/InRelease | grep aptly выплюнет Description: Generated by aptly .
UPD 1. Я таки допишу про создание репы. Итак.
Сначала немного про переменные и конфиги:
my-first-repo — имя репозитория для внутренней кухни aptly.
rolling — имя релиза бубнадебиана, которое будет светиться в sources.list . Можно сделать такое же как имена дистров, т.е. bionic , buster , так и чё-то своё. У меня rolling , потому что пока нет задачи делать специфичные фишки для конкретного релиза
< «rootDir»: «/var/aptly», «downloadConcurrency»: 4, «downloadSpeedLimit»: 0, «architectures»: [], «dependencyFollowSuggests»: false, «dependencyFollowRecommends»: false, «dependencyFollowAllVariants»: false, «dependencyFollowSource»: false, «dependencyVerboseResolve»: false, «gpgDisableSign»: false, «gpgDisableVerify»: false, «gpgProvider»: «gpg», «downloadSourcePackages»: false, «skipLegacyPool»: true, «ppaDistributorID»: «ubuntu», «ppaCodename»: «», «skipContentsPublishing»: false, «FileSystemPublishEndpoints»: <>, «S3PublishEndpoints»: <>, «SwiftPublishEndpoints»: <> >
/var/aptly должен быть создан и туда должен быть »rw» доступ.
Как выложить свой проект на github
Добавлениесоздание репы != публикация . При создании репы — создаётся /var/aptly/pool , в котором есть вроде бы всё нужное, но это не совсем так. Подробнее — в документации. Когда захотите именно пользоваться готовой штукой как mirror.yandex.ru , то надо опубликовать. Тогда в /var/aptly/public создаётся дерево, которое уже можно выставлять по http,ftp,etc.
Юнит systemd , если вы будете общаться с aptly через http:
[Unit] Description=The Aptly api server After=network.target remote-fs.target nss-lookup.target # https://ma.ttias.be/auto-restart-crashed-service-systemd/ StartLimitIntervalSec=500 StartLimitBurst=10 [Service] ExecStart=/usr/bin/aptly api serve -listen=:8080 StandardOutput=syslog StandardError=syslog SyslogIdentifier=aptly User=aptly Group=aptly # WorkingDirectory=/var/aptly # https://ma.ttias.be/auto-restart-crashed-service-systemd/ Restart=on-failure RestartSec=10s [Install] WantedBy=multi-user.target
Создание пустого репозитория:
Через bash:
aptly repo create -distribution=»rolling» my-first-repo
aptly -architectures=i386,amd64 publish repo my-first-repo
Через api:
curl -X POST -H ‘Content-Type: application/json’ —data » http://localhost:8080/api/repos
curl -X POST -H ‘Content-Type: application/json’ —data ‘], «Architectures»: [«i386», «amd64»], «Distribution»: «rolling»>’ http://localhost:8080/api/publish
Через Ansible:
aptly_my_first_repo_name: my-first-repo aptly_my_first_repo_distribution: rolling aptly_api_port: 8080
— name: Create my first repo uri: url: http://localhost:>/api/repos method: POST body_format: json body: Name: «>» DefaultDistribution: «>» status_code: — 201 — 400 tags: — api — repo — create
— name: Publish my first repo uri: url: http://localhost:>/api/repos method: POST body_format: json body: SourceKind: «local» Sources: — Name: «>» Architectures: — i386 — amd64 Distribution: «>» status_code: — 200 — 201 — 400 tags: — api — repo — publish
Как всё выглядит после создания пустого репозитория
Через api
curl —silent http://localhost:8080/api/repos | jq .
Через bash
sudo aptly repo list -raw
my-first-repo
sudo aptly publish list -raw
. rolling
Через ФС
cd /var/aptly/public
. ├── dists │ └── rolling │ ├── InRelease │ ├── main │ │ ├── binary-amd64 │ │ │ ├── Packages │ │ │ ├── Packages.bz2 │ │ │ ├── Packages.gz │ │ │ └── Release │ │ └── binary-i386 │ │ ├── Packages │ │ ├── Packages.bz2 │ │ ├── Packages.gz │ │ └── Release │ ├── Release │ └── Release.gpg ├── pool ├── repo.key └── repo.key.gpg
Добавление пакета
cd /var/aptly/upload wget https://download.cdn.viber.com/cdn/desktop/Linux/viber.deb
Через bash
aptly repo add my-first-repo /var/aptly/upload/viber.deb
aptly publish update rolling
Через apiansible
— name: Add Viber to repo over api when: — ansible_os_family == ‘Debian’ — ansible_pkg_mgr == ‘apt’ — aptly_add_first_software_in_created_repo_over == ‘api’ uri: url: http://localhost:>/api/repos/>/file/viber.deb method: POST status_code: — 200 — 201 — 400
— name: Update published repo over api when: — ansible_os_family == ‘Debian’ — ansible_pkg_mgr == ‘apt’ — aptly_add_first_software_in_created_repo_over == ‘api’ uri: url: http://localhost:>/api/publish/:./> method: PUT body_format: json body: SourceKind: «local» # Sources: [>»>] Sources: — Name: «>» Component: «>» Architectures: — i386 — amd64 Distribution: «>» status_code: — 200 — 201 — 400
Вообще, написана и оттестирована роль для ansible и всё выдернуто оттуда, если что
Источник: ru.stackoverflow.com
Настройка и управление репозиторием Debian с помощью Aptly
Опубликовано: 19.04.2022
Используемые термины: Aptly, Linux. В инструкции мы рассмотрим основные моменты для создания и управления репозиторием для пакетов Deb с помощью инструмента Aptly.
Установка Aptly
Инструкцию по установке мы можем найти на официальном сайте. Давайте ее рассмотрим на примере Ubuntu и Rocky Linux.
Ubuntu (Debian)
Установку Aptly на Deb-системы выполнить, довольно, просто. Необходимо подключить репозиторий разработчика и выполнить установку. Выполним импорт ключа репозитория:
wget -qO — https://www.aptly.info/pubkey.txt | apt-key add —
Добавим репозиторий:
vi /etc/apt/sources.list.d/aptly.list
deb http://repo.aptly.info/ squeeze main
Обновим список пакетов и выполним установку:
apt update
apt install aptly
Для проверки введем команду:
aptly version
Мы должны увидеть что-то на подобие:
aptly version: 1.4.0
Rocky Linux (RPM)
Для дистрибутивов на базе пакетов RPM предлагается для установки скачать и распаковать бинарник. Для начала, нам понадобятся wget и tar:
yum install wget tar
Переходим на страницу последнего релиза и копируем ссылку для загрузки архива: Используя ссылку, скачиваем на наш компьютер архив:
wget https://github.com/aptly-dev/aptly/releases/download/v1.4.0/aptly_1.4.0_linux_amd64.tar.gz
Распакуем архив:
tar zxf aptly*tar.gz
Раскидаем полученные файлы по своим местам:
mv aptly_*_linux_amd64/aptly /usr/local/bin/
gzip -c aptly_*_linux_amd64/man/aptly.1 > /usr/share/man/man1/aptly.1.gz
mkdir /usr/share/doc/aptly
mv aptly_*_linux_amd64/ /usr/share/doc/aptly/
Для проверки введем команду:
aptly version
Мы должны увидеть что-то на подобие:
aptly version: 1.4.0
Начальная настройка
Прежде чем начать работать с репозиторием, создадим конфигурационный файл:
vi /etc/aptly.conf
<
«rootDir»: «/opt/aptly»,
«downloadConcurrency»: 4,
«downloadSpeedLimit»: 0,
«architectures»: [],
«dependencyFollowSuggests»: false,
«dependencyFollowRecommends»: false,
«dependencyFollowAllVariants»: false,
«dependencyFollowSource»: false,
«dependencyVerboseResolve»: false,
«gpgDisableSign»: false,
«gpgDisableVerify»: false,
«gpgProvider»: «gpg»,
«downloadSourcePackages»: false,
«skipLegacyPool»: true,
«ppaDistributorID»: «ubuntu»,
«ppaCodename»: «»,
«FileSystemPublishEndpoints»: <
«pubtest»: <
«rootDir»: «/var/www/aptly»,
«linkMethod»: «symlink»,
«verifyMethod»: «md5»
>
>,
«enableMetricsEndpoint»: false
>
- rootDir — базовая директория для приложения, где будет храниться база репозиториев.
- FileSystemPublishEndpoints — точка публикации для репозитория. Данную опцию мы рассмотрим подробнее ниже.
- pubtest — название для точки публикации.
- rootDir — каталог, в котором должны находить файлы опубликованного репозитория.
- linkMethod — способ создания копии. Возможны варианты: symlink, copy, hardlink. У каждого метода свои плюсы и минусы. Решение на усмотрение администратора репозитория.
Создание и поддержка своего собственного APT репозитория
С появлением нового проекта — sdr-server, у меня стало слишком много приложений, которые нужно как-то устанавливать. И всё бы ничего, но каждое приложение в свою очередь требует разных системных библиотек. А эти системные библиотеки не всегда нужных версий.
А если сюда добавить разные версии дистрибутивов и разные архитектуры процессоров, то начинается комбинаторный взрыв, и всё становится очень запутанным. Для решения этой проблемы можно было бы сделать докер образа и на этом успокоится. Но, во-первых, я планирую запускать эти приложения под RaspberryPI, где ресурсов не так уж много.
Во-вторых, большинство из них написано на Си для получения максимального ускорения. Городить поверх них докер — это значит делать шаг назад. Ну и в-третьих, докер усложнит и без того непростую конфигурацию. Всё это привело меня к единственно правильному решению — созданию собственного APT репозитория.
Требования
- поддержка разных дистрибутивов. Мне нужно поддерживать Debian stretch, Debian buster, Ubuntu bionic и Ubuntu focal. Это две последние стабильные версии двух самых популярных дистрибутивов. Debian прежде всего нужен для RaspberryPI. Все RaspberryPi OS основаны на debian. А Ubuntu — это самый популярный дистрибутив как на сервере, так и среди Linux десктопов.
- поддержка двух архитектур: armhf и amd64. В будущем планируется добавить arm64.
- репозиторий должен быть самодостаточный. Это значит, что все зависимости должны устанавливаться либо из центрального репозитория, либо находится в r2cloud репозитории.
Поддержка разных дистрибутивов
Самый, наверное, главный вопрос: “а зачем вообще явно делать поддержку разных дистрибутивов”? Ubuntu сделан на основе Debian, поэтому достаточно было бы поддерживать Debian разных версий.
Но чем больше я пытался ответить на этот вопрос, тем больше убеждался, что явно разделять дистрибутивы и их версии — это правильное решение.
Зависимости
Самое очевидное преимущество разных версий дистрибутивов — возможность гибко управлять зависимостями. Например, есть такая библиотека check. Эта библиотека для создания юнит тестов на Си. Если ставить её через brew, то поставится версия 0.15.2:
И в версии 0.15.2 есть метод ck_assert_ptr_nonnull . Весьма удобный метод для того, чтобы проверять выделена ли память. Однако, при попытке собрать приложение в Ubuntu, будет возникать ошибка: метод ck_assert_ptr_nonnull не найден. А всё из-за того, что в Ubuntu bionic версия библиотеки 0.10.0. И там этого метода ещё нет.
Эту проблему можно решить несколькими способами:
- Не использовать метод ck_assert_ptr_nonnull и поддерживать минимальную версию check
- Создать отдельную ветку для конкретного дистрибутива, в котором использовать новый метод
- Использовать #if CHECK_VERSION >= 0.11 в исходном коде и превратить его в наслоение разных препроцессорных инструкций
- Запаковать check нужной версии в собственный репозиторий и поставлять его вместе с приложением
Понятное дело, для юнит-тестов 2, 3 и 4 — это перебор. И в моём случае я, скрепя сердцем, переписал юнит-тесты без использования ck_assert_ptr_nonnull . Но для других более важных библиотек, такой способ может и не подойти.
Например, библиотеку volk мне пришлось компилировать и загружать в свой репозиторий.
Компиляция
Компиляция — это ещё один рассадник несовместимости версий и операционных систем. Если приложение скомпилировано более новой версией gcc, то оно вряд ли запустится на операционной системе, где стоит более старая версия.
На практике мне не удалось найти такие пакеты, которые бы запускались на одной версии дистрибутива и не запускались на другой. Но это лишь значит, что я видел недостаточное количество пакетов.
Дизайн APT репозитория
Итак, с поддержкой разных версий дистрибутивов определились. Теперь настала очередь выяснить, а как, собственно, это можно сделать.
Для r2cloud APT репозитория я выбрал следующую схему:
- хостинг — S3
- каждый дистрибутив имеет кодовое имя, которое делается подпапкой
- каждая поддерживаемая архитектура — это подпапка в дистрибутиве
- компонент всегда один — “main”
Получилось нечто такое:
Тут важно заметить, что непосредственно бинарники могут быть переиспользованы между разными дистрибутивами. Они находятся в отдельной директории pool и их можно идентифицировать по имени, версии, компоненту и архитектуре. Вообще, это сделано специально, чтобы уменьшить размер директории pool . Ведь для того, чтобы перенести бинарник в более новые дистрибутивы, достаточно добавить его имя в файл Packages. Однако, это может быть проблемой, если нужно выпускать бинарник не совместимый с предыдущей версией ОС.
Чтобы решить эту проблему, Debian-сообщество рекомендует добавлять название дистрибутива в версию:
0.6.5-1~stretch
Но это может сработать не для всех пакетов, а для тех, которые собираются с source format=quilt. Например, rtl-sdr содержит source format=native, так что мне пришлось делать собственный форк.
Сборка пакетов
Из-за того, что появилось множество различных версий дистрибутивов, сборка сильно усложнилась. Единственным правильным способом собрать пакет под определённую версию ОС будет сборка именно в этой версии ОС.
Чтобы хоть как-то облегчить процесс, я накупил несколько флеш карт и установил на каждую из них свою версию дистрибутива:
Как только мне нужно собрать пакет под конкретную версию ОС, я вставляю нужную флеш карту в RaspberryPI и собираю пакет.
Для сборки под Ubuntu я решил пойти немного другим путём — использовать виртуалки. Они достаточно дешёвые и не нужно держать дома ещё одну железку. Достаточно создать виртуалку с поминутной оплатой и запустить там билд.
armhf vs arm64
Больше всего проблем я получил, собирая volk. Эта библиотека использует ассемблерный код и интристики для того, чтобы ускорять выполнение разных DSP преобразований. Я уже писал недавно о том, как мне удалось её ускорить. Так вот, сборка под RaspberryPI подарила мне много новых ощущений.
Во-первых, в Debian есть две разные архитектуры для 32битного ARM и 64битного ARM. Они называются соответственно armhf и arm64. Собранные пакеты для armhf находятся в разделе binary-armhf, для arm64 — в binary-arm64. Пока всё просто.
Во-вторых, в ARM есть такое расширение — NEON. Это расширение добавляет SIMD операции, с помощью которых можно в несколько раз ускорить приложение. И volk очень активно их использует. Но они не включены по умолчанию в RaspberryPI OS! Поэтому компиляция volk просто игнорирует NEON и производит не самый оптимальный код.
Почему разработчики RaspberryPI по-умолчанию не включают NEON для меня загадка. Ведь они точно знают какой процессор стоит у них на плате. И все процессоры в RaspberryPI имеют это расширение.
В-третьих, RaspberryPI OS существует только для armhf. Именно поэтому, запуская компиляцию на RaspberryPI 4, где стоит процессор с arm64, я получаю пакет для armhf. Однако, volk, при компиляции игнорирует dpkg —print-architecture и определяет процессор как arm64! Он производит код для arm64, тот помещается в пакет для armhf, и RaspberryPI 3 не может его запустить. Бардак.
На поиск и решение всех этих особенностей у меня ушло несколько недель.
Подключение APT репозитория
Но зато подключение репозитория происходит в три строчки:
sudo apt-get install dirmngr lsb-release sudo apt-key adv —keyserver keyserver.ubuntu.com —recv-keys A5A70917 sudo bash -c «echo «deb http://s3.amazonaws.com/r2cloud $(lsb_release —codename —short) main» > /etc/apt/sources.list.d/r2cloud.list»
Самая важная часть — это $(lsb_release —codename —short) . Я просто беру кодовое имя текущей операционной системы и подключаю соответствующую систему из r2cloud репозитория.
apt-html
Количество поддерживаемых дистрибутивов и пакетов стало таким большим, что мне пришлось написать специальную программу — apt-html. Это простая консольная утилита, которая генерирует красивую html страницу со списком пакетов в APT репозитории.
Запускается достаточно просто:
java -jar ./target/apt-html.jar —url http://s3.amazonaws.com/r2cloud —include-arch armhf,amd64 —include-component main —include-codename stretch,bionic,buster,focal —include-package sdr-server,libcpu-features-dev,libvolk2-bin,libvolk2.4-dbgsym,libvolk2.4,librtlsdr0,librtlsdr-dev,librtlsdr0-dbgsym,libiio,plutosdr,r2cloud-jdk,r2cloud-ui,rtl-sdr,wxtoimg,r2cloud —output-dir src/main/resources/
На вход подаётся URL APT репозитория, список архитектур для включения в отчёт, список пакетов, список дистрибутивов, а на выходе получается вот такая симпатичная страничка:
Выводы
Всё это упражнение в создании APT репозитория заняло у меня несколько недель. И это при том, что последние несколько лет я активно пишу всевозможные инструменты для управления apt репозиториями. Я не думаю, что разработчики Debian сознательно сделали систему такой сложной и запутанной.
Скорее всего, со временем она стала обрастать множеством фич и опций, что превратило её в такую, какая она сейчас есть. Несмотря на это, я планирую и дальше развивать r2cloud APT репозиторий и добавлять туда разные полезные пакеты. Ведь это единственный простой способ для конечного пользователя взять и установить программу.
Пара идей на будущее:
- добавить поддержку arm64
- создать баг или pull request в RaspberryPI OS, чтобы включить опцию GCC “-mfpu=neon” по-умолчанию
- возможно, создать rack из нескольких RaspberryPI и похожих плат на Intel, чтобы сделать небольшую билд ферму
Источник: dernasherbrezon.com