check-unmets

check-unmets — это пакет программ, призванных облегчить массовое обновление репозитария, содержащегося на базе girar. Такое массовое обновление может возникнуть, например, при портировании репозитария на другую аппаратную архитектуру. Пакет включает в себя средства для автоматического выявления проблем, информировании о выявленных проблемах через web-интерфейс и решения выявленных проблем в автоматическом и полуавтоматическом режимах. В настоящее время пакет check-unmets используется в проекте Ports/arm.

Инструментарий пакета можно разделить на две категории:

• инструменты, облегчающие обслуживание и реформирование репозитария;
• инструменты для анализа пакетных зависимостей и помощи в формировании сборочных заданий.

Обслуживание репозитария

Подсистема обслуживания репозитария состоит из следующих компонентов:

• интерфейс пользователя — программа для вывода информации о заданиях и предлагаемых сценариев продолжения сборки;

• база данных заданий — подсистема для хранения информации о сборочных заданиях, ошибках сборки и предполагаемых путях их устранения;

• анализатор заданий — программа, актуализирующая информацию о задании на основании анализа его структурных элементов и журнала;

• резолвер — программа, призванная разрешать проблемы, связанные с неудовлетворёнными межпакетными зависимостями, возникающими при сборке.

Интерфейс пользователя

Описание страниц

На страницы пользовательского интерфейса информация о сборочных заданиях выводится в табличной форме. Помимо данных, непосредственно характеризующих задание, выводится информация о выявленных в процессе сборки неудовлетворённых межпакетных зависимостях и найденных пакетах-кандидатах, предоставляющих недостающие компоненты. Эта информация сопровождается ссылками на те сборочные задания, в рамках которых предпринимались попытки собрать пакеты-кандидаты.

На заглавную страницу выводится информация о недавних сборочных заданиях, начиная с самых новых. Вверху страницы выводится заголовок с пояснениями и сводка по общему числу проблемных заданий, заданий, рекомендуемых к перезапуску, пакетов, ожидающих портирования и пакетов, которые должны быть удалены. Сводка сопровождается ссылками на другие страницы интерфейса, на которые выводится информация о заданиях, соответствующих определённым дополнительным критериям и сценарии, рекомендующие к запуску новые задания.

На одну из дополнительных страниц выводится таблица с заданиями, которые система рекомендует к перезапуску. Отбираются не прошедшие сборку задания, для которых на данный момент удовлетворены зависимости на все те компоненты, которых ранее не хватало. Кроме табличной формы, может быть выведен готовый к запуску сценарий оболочки, позволяющий перезапустить задания. Для старых заданий, информация о которых сохранилась только в базе данных, вместо команд перезапуска выводятся команды, добавляющие в очередь новые задания, аналогичные старым. Для предотвращения многократного перезапуска одних и тех же заданий, из выборки можно исключить задания, запускавшиеся более заданного количества раз. Предусмотрены параметры для настройки сценариев под учётную запись определённого пользователя сборочной системы.

На другую дополнительную страницу выводится сценарий оболочки для постановки в очередь сборочных заданий на портирование пакетов-кандидатов, предоставляющих компоненты, которых на данный момент не хватает для успешного выполнения одного или нескольких сборочных заданий. В комментарии к каждой команде сценария указывается количество заданий, ожидающих портирования данного пакета. В начале сценария помещаются команды на портирование самых востребованных компонентов.

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

Некоторые пакеты могут иметь зависимости на несуществующие или недоступные компоненты. Такие пакеты должны быть либо обновлены, и тогда они рекомендуются к портированию, либо, в ряде случаев, удалены. Для этой цели существует дополнительная страница интерфейса, на которую выводится сценарий на удаление пакетов.

Методика работы

Сборочные задания на портирование пакетов добавляются обычным образом, через командный интерфейс сборочной системы. Результат обработки заданий оценивается по таблице на заглавной странице интерфейса. Следует периодически просматривать информацию о сборках, обращая особое внимание на отмеченные красным цветом неудачные сборки, имеющие статус «failed». Если для сборки были выявлены неудовлетворённые зависимости на определённые компоненты системы, следует дождаться когда эта информация будет обработана резолвером. После этого, выявленные резолвером недостающие исходные пакеты следует добавить в очередь сборки, если это не было сделано ранее. Для этого можно воспользоваться готовым сценарием на дополнительной странице. Если анализ показал, что все компоненты, которые ранее отсутствовали в репозитарии, к настоящему моменту уже предоставляются одним или более пакетами, то сборочное задание следует перезапустить, для чего можно воспользоваться готовым сценарием на дополнительной странице. Следует периодически просматривать сценарий удаления пакетов и вводить в систему указанные там команды, очищая репозитарий от ошибочных сборок и старых пакетов, блокирующих сборку новых. Проблемы, не связанные с неудовлетворёнными зависимостями требуют непосредственного анализа журнальных файлов.

Перед перезапуском задания, особенно если перезапуск выполняется не в первый раз, следует обратиться к журналу последней сборки и оценить вероятность удачной сборки в текущих условиях.

База данных заданий

Таблицы

• tasks — Общие данные о сборочном задании:
  • id — номер задания в сборочной системе;
  • try — порядковый номер попытки;
  • owner — имя пользователя, добавившего задание в очередь;
  • status — статус задания;
  • failed — наименование этапа на котором сборка завершилась с ошибкой;
  • details — набор кратких цитат из журнала сборки, предположительно связанных с неудачей;
  • modify — верменно́й штамп.

• gears — Данные о подзадании, обрабатываемом в рамках задания:
  • task — номер задания в сборочной системе (соответствует полю id таблицы tasks);
  • type — тип подзадания (сборка из gear-репозитария, сборка из SRPM, удаление пакета);
  • name — имя репозитария или пакета;
  • tagname — имя тега (для сборок из gear);
  • status — статус обработки подзадания;
  • package — имя пакета без версии;
  • version — версия пакета.

Исходный код

• check-unmets

Лицензия

• GPL версии 2 и выше.