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 для исходного и целевого репозиториев, и база данных заданий.

Алгоритм разрешения зависимостей

Из таблицы resolve удаляются все записи, связанные с последними известными неудачными попытками сборки пакетов — эта информация должна быть актуализирована.
Последовательно обрабатываются все записи таблицы task_missing не имеющие соответствий в таблице resolve.
- Прежде всего, каждая зависимость проверяется на действительность и актуализируется: за время, прошедшее с момента фиксации зависимости она могла измениться или пакет мог вовсе утратить её в результате пересборки.
  - Если актуальная зависимость не обнаружена, то она фиктивно разрешается сама на себя;
  - иначе данные о зависимости актуализируются, что, в частности, может привести к уточнению требуемой версии компонента;
- Далее производится поиск пакетов, удовлетворяющих данную зависимость в целевом (локальном) репозитории.
  - Если пакет-кандидат, предоставляющий компонент, был найден, то зависимость разрешается на этот пакет с указанием типа (l).
- Затем поиск пакета-кандидата производится в исходном (удалённом) репозитории.
  - Если пакет-кандидат был обнаружен там, то зависимость разрешается на этот пакет с указанием типа (r).
- Если ни один пакет-кандидат так и не был найден, но известен пакет, непосредственно требующий недостающий компонент, то выполняется проверка наличия данной неудовлетворённой зависимости в исходном репозитории.
  - Если в исходном репозитории аналогичный пакет не имеет данной зависимости, то делается вывод о том, что данный пакет в целевом репозитории либо устарел, либо был некорректно собран.
    - При наличии в исходном репозитории более старшей версии пакета по сравнению с целевым репозиторием, исходные данные о неодовлетворённой зависимости подменяются зависимостью на более новую версию пакета, что должно вызвать рекомендацию данной версии пакета к портированию.
    - При равенстве версий пакетов в исходном и целевом репозиториях, делается вывод о том, что пакет в целевом репозитории был некорректно собран, должен быть удалён и собран вновь. Данные о соответствующей операции добавляются в таблицу операций.
  - Если неудовлетворённая зависимость имеет место быть и в исходном репозитории, то на этот счёт делается веское предупреждение.
  - В том случае, если в исходном репозитории аналогичный пакет попросту отсутствует, то делается вывод о том, что пакет должен быть удалён и из целевого репозитория. Данные о соответствующей операции добавляются в таблицу операций.
- В случае, если пакет, непосредственно требующий недостающий компонент, отсутствует в целевом репозитории (очевидно, был удалён), то запись о неудовлетворённой зависимости удаляется.

Точки вызова

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

Базовый инструментарий

Исходный код

check-unmets

Лицензия

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