Git.alt/Введение

Материал из ALT Linux Wiki

Введение в git.alt

git.alt — это сервер совместной разработки gear-репозиториев ALT Linux Team.

Хостинг git-репозиториев (girar)

Одной из подсистем Git.alt является Girar (хостинг git-репозиториев); girar осуществляет доступ разработчиков к git-репозиториям. Каждый разработчик имеет собственные копии git-репозиториев, в которые он может вносить, вообще говоря, достаточно произвольные изменения (предлагая, таким образом, включить эти изменения в очередную версию пакета). Реализована система почтовых уведомлений, которая упрощает обмен изменениями. При этом фактический обмен и аккумуляция изменений осуществляется средствами распределённой системы контроля версий 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) содержит исправления критических ошибок.

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