Git.alt/Введение: различия между версиями

Текущая версия от 18:11, 1 сентября 2011

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

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

@@ Строка 3: / Строка 3: @@
 <tt>git.alt</tt> — это сервер совместной разработки gear-репозиториев ALT Linux Team.
-== gear-репозитории ==
+== Хостинг git-репозиториев (girar) ==
-Одной из подсистем <tt>git.alt</tt> является
+Одной из подсистем [[Git.alt]] является [[Girar]] (хостинг git-репозиториев);
-<tt>girar</tt> (архив gear-репозиториев); <tt>girar</tt> осуществляет доступ
+<tt>girar</tt> осуществляет [[git.alt/Справочник#access|доступ]] разработчиков к git-репозиториям.
-разработчиков к gear-репозиториям. Каждый разработчик имеет собственные
+Каждый разработчик имеет собственные копии git-репозиториев, в которые он может вносить, вообще говоря,
-копии gear-репозиториев, в которые он может вносить, вообще говоря, достаточно
+достаточно произвольные изменения (предлагая, таким образом, включить эти изменения
-произвольные изменения (предлагая, таким образом, включить эти изменения
+в очередную версию пакета). Реализована система [[git.alt/Справочник#email|почтовых уведомлений]],
-в очередную версию пакета). Реализована система почтовых уведомлений,
 которая упрощает обмен изменениями. При этом фактический обмен и аккумуляция
 изменений осуществляется средствами распределённой системы контроля версий <tt>git</tt>.
@@ Строка 17: / Строка 16: @@
 окончательную версию пакета могут подготовить только один или несколько
 разработчиков, за которыми закреплён этот пакет (maintainers). Контроль
-осуществляется подсистемой <tt>ACL</tt>, и «неавторизированные»
+осуществляется подсистемой [[ACL]], и «неавторизированные»
 версии пакетов по умолчанию отвергаются (вместе с тем, сохранена возможность
 для т. н. NMU, non-maintainer upload).
-== Сборка (girar-builder) ==
+== Сборка пакетов (girar-builder) ==
 Когда новая версия пакета окончательно подготовлена, разработчик делает
-в gear-репозитории ''метку'' (tag) с криптографической подписью и инициирует запрос
+в gear-репозитории ''метку'' (tag) с криптографической подписью и [[git.alt/Справочник#build|инициирует запрос]]
-на сборку пакета. Запрос обрабатывается сборочной системой <tt>girar-builder</tt>
+на сборку пакета. Запрос обрабатывается сборочной системой [[girar-builder]].
 Сборочная система взаимодействует с ''кеширующим сервером'' gear-репозиториев.
 Если запрос на сборку был обработан успешно, то собранные rpm-пакеты помещаются в репозиторий
-rpm-пакетов, а gear-репозиторий с новой меткой публикуется на кеширующем сервере. Названия
+rpm-пакетов, а gear-репозиторий с новой меткой [[git.alt/Справочник#gears|публикуется]] на кеширующем сервере. Названия
 gear-репозиториев на кеширующем сервере совпадают с именами src.rpm-пакетов (это требование не
 является обязательным для gear-репозиториев разработчиков). Таким образом, кеширующий сервер
@@ Строка 36: / Строка 35: @@
 === Задания и транзакции ===
-''Задание'' состоит из~одного или нескольких gear-репозиториев (и их меток),
+''Задание'' состоит из одного или нескольких gear-репозиториев (и их меток),
 отправленных на сборку. Сборочная система сначала осуществляет ''первичную сборку''
 пакетов. Если при первичной сборке пакетов возникли грубые ошибки, то задание автоматически
@@ Строка 52: / Строка 51: @@
 : Если при помещении пакетов в репозиторий возникают новые неудовлетворенные зависимости, то по умолчанию такой переход не может быть разрешён.
 ; Тестовая пересборка пакетов
-: в наибольшей степени обнаруживает взаимное влияние между пакетами. Эта проверка может быть довольно ресурсоемкой: должны быть пересобраны все пакеты, у которых в сборочной среде оказывается хотя бы один новый пакет из транзакции. Если же хотя бы один новый пакет их транзакции входит в базовую сборочную среду, то потребуется полная тестовая пересборка всего репозитория rpm-пакетов. Сборочная система фиксирует не только саму возможность пересборки, но и изменение зависимостей у пересобранных пакетов.
+: в наибольшей степени обнаруживает взаимное влияние между пакетами. Эта проверка может быть довольно ресурсоемкой: должны быть пересобраны все пакеты, у которых в сборочной среде оказывается хотя бы один новый пакет из транзакции. Если же хотя бы один новый пакет из транзакции входит в базовую сборочную среду, то потребуется полная тестовая пересборка всего репозитория rpm-пакетов. Сборочная система фиксирует не только саму возможность пересборки, но и изменение зависимостей у пересобранных пакетов.
 ; Идентичность noarch пакетов
 : при сборке на всех архитектурах.
@@ Строка 61: / Строка 60: @@
 Воздействовать на задания в отложенном режиме можно, в основном, двумя способами:
-* Добавление новых пакетов, которые исправляют нарушения.
+* [[git.alt/Справочник#build|Добавление]] новых пакетов, которые исправляют нарушения.
 Например, если у библиотеки изменилось имя (soname), то в репозитории могут образоваться неудовлетворённые зависимости на старое имя библиотеки.
 Тогда в задание можно добавить все пакеты, которые зависят от старой библиотеки, чтобы пересобрать их с новой библиотекой.