Git.alt/Введение
Введение в git.alt
git.alt — это сервер совместной разработки gear-репозиториев ALT Linux Team.
gear-репозитории
Одной из подсистем git.alt является girar (архив gear-репозиториев); girar осуществляет доступ разработчиков к gear-репозиториям. Каждый разработчик имеет собственные копии gear-репозиториев, в которые он может вносить, вообще говоря, достаточно произвольные изменения (предлагая, таким образом, включить эти изменения в очередную версию пакета). Реализована система почтовых уведомлений, которая упрощает обмен изменениями. При этом фактический обмен и аккумуляция изменений осуществляется средствами распределённой системы контроля версий git.
Несмотря на то, что любой разработчик может внести изменения в пакет, окончательную версию пакета могут подготовить только один или несколько разработчиков, за которыми закреплён этот пакет (maintainers). Контроль осуществляется подсистемой ACL, и «неавторизированные» версии пакетов по умолчанию отвергаются (вместе с тем, сохранена возможность для т. н. NMU, non-maintainer upload).
Сборка (girar-builder)
Когда новая версия пакета окончательно подготовлена, разработчик делает в gear-репозитории метку (tag) с криптографической подписью и инициирует запрос на сборку пакета. Запрос обрабатывается сборочной системой girar-builder Сборочная система взаимодействует с кеширующим сервером gear-репозиториев. Если запрос на сборку был обработан успешно, то собранные rpm-пакеты помещаются в репозиторий rpm-пакетов, а gear-репозиторий с новой меткой публикуется на кеширующем сервере. Названия gear-репозиториев на кеширующем сервере совпадают с именами src.rpm-пакетов (это требование не является обязательным для gear-репозиториев разработчиков). Таким образом, кеширующий сервер предоставляет доступ к «официальным» gear-репозиториям, содержимое которых соответствует фактическим сборкам пакетов.
Задания и транзакции
Задание состоит из одного или нескольких gear-репозиториев (и их меток), отправленных на сборку. Сборочная система сначала осуществляет первичную сборку пакетов. Если при первичной сборке пакетов возникли грубые ошибки, то задание автоматически отменяется. В противном случае, если все пакеты в задании успешно собрались, то открывается транзакция: генерируется временный репозиторий, в котором выполняется ряд проверок (вычисляются характеристики нового репозитория). По умолчанию переход в новое состояние разрешён, только если характеристики репозитория не ухудшились. Если же собранные пакеты ухудшают характеристики репозитория, то составляется список нарушений, и задание переводится в отложенный режим.
Характеристики репозитория
Сборочная среда, помимо прочих, выполняет следующие проверки:
- Неудовлетворённые зависимости (unmet dependencies).
- Если при помещении пакетов в репозиторий возникают новые неудовлетворенные зависимости, то по умолчанию такой переход не может быть разрешён.
- Тестовая пересборка пакетов
- в наибольшей степени обнаруживает взаимное влияние между пакетами. Эта проверка может быть довольно ресурсоемкой: должны быть пересобраны все пакеты, у которых в сборочной среде оказывается хотя бы один новый пакет из транзакции. Если же хотя бы один новый пакет из транзакции входит в базовую сборочную среду, то потребуется полная тестовая пересборка всего репозитория rpm-пакетов. Сборочная система фиксирует не только саму возможность пересборки, но и изменение зависимостей у пересобранных пакетов.
- Идентичность noarch пакетов
- при сборке на всех архитектурах.
- Нарушение ACL
- у какого-либо пакета в задании не относится, строго говоря, к характеристикам репозитория; однако включение его в общий список нарушений транзакции упрощает NMU.
Управление отложенными заданиями
Воздействовать на задания в отложенном режиме можно, в основном, двумя способами:
- Добавление новых пакетов, которые исправляют нарушения.
Например, если у библиотеки изменилось имя (soname), то в репозитории могут образоваться неудовлетворённые зависимости на старое имя библиотеки. Тогда в задание можно добавить все пакеты, которые зависят от старой библиотеки, чтобы пересобрать их с новой библиотекой.
- Разрешение нарушений.
Например, администратор git.alt может разрешить нарушение ACL, если «неавторизированная» версия пакета (NMU) содержит исправления критических ошибок.
Таким образом, задания могут переводиться в отложенный режим и позднее возобновляться. Если все нарушения были сняты, то выполняется транзакционный переход репозитория в новое состояние.