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) содержит исправления критических ошибок.

Таким образом, задания могут переводиться в отложенный режим и позднее возобновляться. Если все нарушения были сняты, то выполняется транзакционный переход репозитория в новое состояние.