check-unmets
check-unmets — это пакет программ, призванных облегчить массовое обновление репозитория, содержащегося на базе girar. Такое массовое обновление может возникнуть, например, при портировании репозитория на другую аппаратную архитектуру. Пакет включает в себя средства для автоматического выявления проблем, информировании о выявленных проблемах через web-интерфейс и решения выявленных проблем в автоматическом и полуавтоматическом режимах. В настоящее время пакет check-unmets используется в проекте Ports/arm.
Инструментарий пакета можно разделить на две категории:
- инструменты, облегчающие обслуживание и реформирование репозитория;
- инструменты для анализа пакетных зависимостей и помощи в формировании сборочных заданий.
Обслуживание репозитория
Подсистема обслуживания репозитория состоит из следующих компонентов:
- интерфейс пользователя — программа для вывода информации о заданиях и предлагаемых сценариев продолжения сборки;
- база данных заданий — подсистема для хранения информации о сборочных заданиях, ошибках сборки и предполагаемых путях их устранения;
- анализатор заданий — программа, актуализирующая информацию о задании на основании анализа его структурных элементов и журнала;
- резолвер — программа, призванная разрешать проблемы, связанные с неудовлетворёнными межпакетными зависимостями, возникающими при сборке.
Интерфейс пользователя
Описание страниц
На страницы пользовательского интерфейса информация о сборочных заданиях выводится в табличной форме. Помимо данных, непосредственно характеризующих задание, выводится информация о выявленных в процессе сборки ошибках, неудовлетворённых межпакетных зависимостях и найденных пакетах-кандидатах, предоставляющих недостающие компоненты. Эта информация сопровождается ссылками на те сборочные задания, в рамках которых предпринимались попытки собрать пакеты-кандидаты.
На заглавную страницу выводится информация о недавних сборочных заданиях, начиная с самых новых. Вверху страницы выводится заголовок с пояснениями и сводка по общему числу проблемных заданий, заданий, рекомендуемых к перезапуску, пакетов, ожидающих портирования и пакетов, которые должны быть удалены. Сводка сопровождается ссылками на другие страницы интерфейса, на которые выводится информация о заданиях, соответствующих определённым дополнительным критериям и сценарии, рекомендующие к запуску новые задания.
На одну из дополнительных страниц выводится таблица с заданиями, которые система рекомендует к перезапуску. Отбираются не прошедшие сборку задания, для которых на данный момент удовлетворены зависимости на все те компоненты, которых ранее не хватало. Кроме табличной формы, может быть выведен готовый к запуску сценарий оболочки, позволяющий перезапустить задания. Для старых заданий, информация о которых сохранилась только в базе данных, вместо команд перезапуска выводятся команды, добавляющие в очередь новые задания, аналогичные старым. Для предотвращения многократного перезапуска одних и тех же заданий, из выборки можно исключить задания, запускавшиеся более заданного количества раз. Предусмотрены параметры для настройки сценариев под учётную запись определённого пользователя сборочной системы.
На другую дополнительную страницу выводится сценарий оболочки для постановки в очередь сборочных заданий на портирование пакетов-кандидатов, предоставляющих компоненты, которых на данный момент не хватает для успешного выполнения одного или нескольких сборочных заданий. В комментарии к каждой команде сценария указывается количество заданий, ожидающих портирования данного пакета. В начале сценария помещаются команды на портирование самых востребованных компонентов.
Та часть проблемных заданий, для которой не было выявлено неудовлетворённых межпакетных зависимостей, выводится на отдельную страницу с пометкой, что данные задания требуют ручного вмешательства.
Некоторые пакеты могут иметь зависимости на несуществующие или недоступные компоненты. Такие пакеты должны быть либо обновлены, и тогда они рекомендуются к портированию, либо, в ряде случаев, удалены. Для этой цели существует дополнительная страница интерфейса, на которую выводится сценарий на удаление пакетов.
Методика работы
Сборочные задания на портирование пакетов добавляются обычным образом, через командный интерфейс сборочной системы. Результат обработки заданий оценивается по таблице на заглавной странице интерфейса. Следует периодически просматривать информацию о сборках, обращая особое внимание на отмеченные красным цветом неудачные сборки, имеющие статус «failed». Если для сборки были выявлены неудовлетворённые зависимости на определённые компоненты системы, следует дождаться когда эта информация будет обработана резолвером. После этого, выявленные резолвером недостающие исходные пакеты следует добавить в очередь сборки, если это не было сделано ранее. Для этого можно воспользоваться готовым сценарием на дополнительной странице. Если анализ показал, что все компоненты, которые ранее отсутствовали в репозитории, к настоящему моменту уже предоставляются одним или более пакетами, то сборочное задание следует перезапустить, для чего можно воспользоваться готовым сценарием на дополнительной странице. Следует периодически просматривать сценарий удаления пакетов и вводить в систему указанные там команды, очищая репозиторий от ошибочных сборок и старых пакетов, блокирующих сборку новых. Проблемы, не связанные с неудовлетворёнными зависимостями требуют непосредственного анализа журнальных файлов.
Перед перезапуском задания, особенно если перезапуск выполняется не в первый раз, следует обратиться к журналу последней сборки и оценить вероятность удачной сборки в текущих условиях.
Ограничения
- Программа поддерживает только СУБД MySQL.
- Доступ к БД производится по жёстко закодированным реквизитам.
База данных заданий
Таблицы
tasks
— Общие данные о сборочном задании:id
— номер задания в сборочной системе;try
— порядковый номер попытки;owner
— имя пользователя, добавившего задание в очередь;status
— статус задания;failed
— наименование этапа на котором сборка завершилась с ошибкой;details
— набор кратких цитат из журнала сборки, предположительно связанных с неудачей;modify
— верменно́й штамп.
gears
— Данные о подзадании, обрабатываемом в рамках задания:task
— номер задания в сборочной системе (соответствует полюid
таблицыtasks
);type
— тип подзадания (сборка изgear
-репозитория, сборка из SRPM, удаление пакета);name
— имя репозитория или пакета;tagname
— имя тега (для сборок изgear
);status
— статус обработки подзадания;package
— имя пакета без версии;version
— версия пакета.
task_missing
— Данные о недостающем для выполнения задания компоненте:task_id
— номер задания в сборочной системе (соответствует полюid
таблицыtasks
);type
— тип зависимости (непосредственная —m
, опосредованная —u
);requisite
— выражение, определяющее имя и границы версии компонента;consumer
— имя и версия пакета, непосредственно требующего компонент.
resolve
— Данные о найденных пакетах-кандидатах, предоставляющих определённый компонент:requisite
— выражение, определяющее имя и границы версии компонента (соответствует одноимённому полю таблицыtask_missing
);package
— имя пакета без версии;version
— версия пакета;type
— тип разрешения зависимости (локальный —L
или удалённый —R
).
actions
— Очередь операций:time
— верменно́й штамп;package
— имя пакета без версии;version
— версия пакета;action
— код операции (r
— удаление с последующей пересборкой,d
— удаление).
Анализатор заданий
Программа update-tasks
используется для добавление в БД заданий информации о задании и последующего её обновления (актуализации).
Функциональные блоки
Анализ структурных элементов задания включает в себя анализ файлов и поддиректорий в директории соответствующей номеру задания, без анализа журнальных файлов. В результате анализа определяется номер задания, его статус и параметры составляющих его подзаданий. На основании успешно собранных исходных пакетов актуализируется информация об имени и версии каждого из них. Данная процедура полезна по той причине, что до фактической сборки исходного пакета, в качестве его имени и версии используется наименование gear
-репозитория и имя сборочного тега.
На основании полученных данных заполняются записи в таблицах tasks
и gears
.
Анализ журналов сборки включает в себя:
- scan_fails
- выявление этапов сборки, завершившихся неудачно;
- scan_missing
- поиск информации о недостающих компонентах системы, необходимых для выполнения сборочного задания;
- scan_unmets
- поиск информации о недостающих компонентах системы, выявленных в процессе установки пакетов;
- scan_makerrs
- выявление целей Makefile, завершившихся неудачно;
- scan_chkerrs
- выявление проверок Sisyphus-check, завершившихся неудачно.
Анализ производится преимущественно регулярными выражениями.
На основании полученных данных дополняется запись в таблице tasks
и таблица task_missing
.
Точки вызова
Следует настроить сборочную систему так, чтобы программа update-tasks
вызывалась как минимум, при:
- постановке задания в очередь (пример модификации сценария
girar-task-run
); - при выборе сборочного задания для обработки (пример модификации сценария
gb-select-task
); - после обработки сборочного задания (пример модификации сценария
gb-run-task
).
В настоящее время инструментарий не предусматривает специальной программы для удаления записи о задании из БД, однако это может быть сравнительно просто достигнуто несколькими вызовами утилиты mysql
. Пример модификации сценария girar-task-rm
для удаления связанных с заданием записей при его явном удалении из очереди.
Ограничения
- Программа поддерживает только СУБД MySQL.
- По причине неразвитого интерфейса командной строки доступ к БД производится по жёстко закодированным реквизитам.
Резолвер
Программа check-unmets
имеет несколько режимов работы, и один из них — запуск программы apt-resolve-db
, фиксирующей в БД информацию о возможных путях разрешения неудовлетворённых межпакетных зависимостей, полученную посредством использования функциональных средств библиотечного модуля AptResolve.pm
.
Исходными данными для запуска программы являются конфигурационные файлы подсистемы apt
для исходного и целевого репозиториев, и база данных заданий.
Исходный код
Лицензия
- GPL версии 2 и выше.