Обсуждение участника:Nir
Руководство мейнтейнера ALT Linux
Введение
Данная статья предназначена для централизации всей информации о процессе работы над репозиторием Sisyphus и интеграции в сообщество ALT Linux (Team).
Для индивида может существовать множество причин стать участником сообщества:
- Желание внести свой вклад в развитие открытого ПО и сделать мир лучше;
- Желание "отполировать резюме" и показать рекрутёрам свои навыки;
- Желание решить вполне себе практическую проблему - например, воспользоваться конкретной программой;
- Вы, волей судьбы, стали эксплуатантом дистрибутива в коммерческой или государственной структуре и сталкиваетесь с проблемами, которые надо как-то решать.
Кто такой мейнтейнер
Мейнтейнер (дистрибутива или пакета) - это человек, который занимается тем, что интегрирует ПО в дистрибутив и сопровождает его впоследствии. То есть делает пакет для установки программы из централизованного репозитория, чинит обнаруженные в программе баги, общается с разработчиками программы, старается реагировать на нужды пользователей (багрепорты, вопросы).
В понимании ALT Linux - мейнтейнер должен быть членом ALT Linux Team (Команды ALT Linux).
Что такое ALT Linux Team
ALT Linux Team - распределённая и независимая команда энтузиастов, которые совместно работают над поддержкой наборов программ в репозитории Sisyphus и собирают дистрибутивы на основе этого репозитория.
Как стать членом ALT Linux Team
Существует процедура принятия в ALT Linux Team, которая называется Join (присоединение). Обычно, этот процесс происходит естественно, когда человек активно участвует в работе сообщества:
- Тестирует ПО и заводит багрепорты о найденных багах;
- Помогает чинить баги - присылает патчи;
- Пакетирует новое ПО или помогет поддерживать существующие пакеты.
Взаимодействие членов команды осуществляется с помощью разнообразных средств связи (сложилось исторически):
- Sisyphus - репозиторий ПО;
- bugzilla.altlinux.org - багтрекер проекта;
- lists.altlinux.org - списки рассылки проекта;
- #altlinux и #altlinux-devel - IRC каналы;
- forum.altlinux.org - форум сообщества.
Процедура Join
Формально, Join выглядит как создание бага на ALT Linux Bugzilla в разделе Development, с параметрами:
- Product == Team Accounts
- Component == Join
К заявке надо приложить/указать:
- Публичный ключ SSH - для доступа к ресурсам сборочницы;
- Публичный GPG-ASCIIARMOR ключ для подписи коммитов;
- Указать никнейм ментора из команды;
- Указать желаемый почтовый адрес вида <nickname>@altlinux.org
В качестве теста на членство в команде принимается работа в виде Gear-репозитория новой программы или возрождение выпавшей из сборок.
Чтобы указать имя ментора (члена команды, который научит собирать и спопровождать пакеты) необходимо предварительно получить его согласие на менторинг. Оптимальный вариант - договориться об этом в личной переписке по e-mail.
Актуальный список менторов:
- sin@
- mike@
- iv@ - только оффлайн менторинг
Работа с пакетной базой
Экосистема ALT Linux обладает многими уникальными наработками и своей интересной историей и архитектурой.
Введение в Gear-репозитории
Gear-репозиторий представляет собой репозиторий Git DVCS, содержаший RPM specfile и специальную директорию .gear с инструкциями по сборке пакета для RPM. Практически всегда (но это не является неприкосновенным правилом) в репозитории также хранится и код программы.
К сожалению, Gear, как и Git - очень сложный и гибкий инструмент вида всё наружу. Есть много вариантов хранения программ в gearrepo, которые могут создать проблемы начинающему меёнтейнеру или заставить поломать голову опытного. Не существует однообразного рецепта работы с gearrepo, так что не стесняйтесь посоветоваться с участниками сообщества по тем или иным вопросам.
Есть некоторые общие рекомендации, которых можно придерживаться:
- Хранить код программы с редкими исправлениями удобно в ветке master - там же, где находятся specfile и директория .gear;
- Хранить код программы отдельно, в ветке upstream, удобно, когда в программу вносится много изменений и история правок specfile или правил Gear мешает следить за ходом работы.
Нюансы сборки пакетов
- При жалобах на зашитый в ПО RPATH удаляйте его при сборке с помощью программы chrpath. Раньше использование RPATH было очень популярно (особенно в системе сборки automake/libtool), но потом мейнтейнеры пришли к выводу, что это мешает искать библиотеки в стандартных путях. Потому, не оставляйте RPATH без особой необходимости.
- Если у программы есть плагины, документация, заголовочные файлы - разместите их в отдельных пакетах.
- Если у программы есть жёсткие опциональные зависимости (например, варианты зависимости от MySQL/MariaDB и от PostgreSQL) - соберите программу в нескольких вариантах, чтобы позволить пользователям не тянуть лишние зависимости, когда они не нужны.
- Если пользователям могут одновременно понадобиться обе версии программы - старая и новая - соберите два пакета с разными именами. Также обдумайте интеграцию с системой Alternatives и вариант небольшого скрипта-обёртки при таком подходе.
- Если программа явлется демоном - удостоверьтесь в наличии предоставляемых файлов .service для systemd и скрипта для sysvinit.
- Политика дистрибутива такова, что не должно быть программ с suid-битом (как sudo). Существует много вариантов решения проблемы. В данном случае необходимо проконсультироваться с членами ALT Linux Team касательно разумного выхода из сложившейся ситуации.
- Если Вы импортировали RPM specfile из другого дистрибутива - оставьте прежний changelog, а свои изменения дописывайте отдельно - это дань уважения авторам.
Подготовка локального сборочного окружения
Установка пакетов для разработки
Для разработки пакетов нам необходим сборочный тулчейн - rpm, hasher, gear и вспомогательные программы.
Обновите систему, чтобы получить свежие версии пакетов программ:
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo shutdown -r now
и после перезагрузки установите следующие пакеты:
$ sudo apt-get install git \
gear \
hasher \
hasher-priv \
hasher-rich-chroot \
hasher-rich-chroot-user-utils \
build-environment \
rpm-utils \
rpm-build \
rpm-build-licenses \
rpm-macros-cmake \
rpm-macros-make \
rpm-macros-generic-compat \
apt-repo \
apt-repo-tools
Настройка Git
Начальная настройка Git выполняется двумя командами:
git config --global user.name "Vasiliy Petrov"
git config --global user.email "vasip@altlinux.org"
Настройка RPM
Добавьте в файл ~/.rpmmacros следующие строки, совпадающие с конфигурацией GPG2 и Git:
%packager Vasiliy Petrov <vasip@altlinux.org>
%_gpg_name vasip@altlinux.org
Создание пользователей Hasher
Hasher использует двух пользователей внутри своего изолированного окружения, чтобы предотвратить атаки на хост-систему из пакетов. Нам необходимо сконфигурировать этих пользователей для аккаунта, от имени которого будет производиться процесс сборки пакетов. Сделать это можно следующей командой:
sudo /usr/sbin/hasher-useradd <user>
Где <user> - имя пользователя. Для того, чтобы изменения к пользователю (попадание в две вспомогательных группы hasher) вступили в силу необходимо выйти из аккаунта и зайти снова.
Hasher configuration
create the `~/hasher/config` file with the following contents:
USER=nir
packager="`rpm --eval %packager`"
no_sisyphus_check="packager,buildhost,gpg"
apt_config="$HOME/.hasher/apt.conf
mount=/dev/pts,/proc
Инициализация Hasher
Run the following commands:
$ mkdir ~/hasher
$ mkdir ~/.hasher
$ hsh --initroot-only ~/hasher
to finish the setup process.
Создание Gear-репозитория из исходных кодов
Мы будем создавать Gear-репозиторий с хранением кода в отдельной ветви - upstream и несколькими зависимыми пакетами (документация, плагины).
Сначала создайте директорию проекта и инициализируйте её:
mkdir program
cd program
git init
В директории проекта могут быть следующие файлы:
- .gear/rules -
- .gear/merge -
- .gear/tags/list -
Далее нам необходимо задать базовую структуру репозитория. Создаём директорию настроек gearrepo:
mkdir -p .gear/tags
touch .gear/rules
touch .gear/tags/list