Схема работы сети автоматической сборки (autobuilder)
Сердцем системы является база данных wanna-build, в которой отслеживаются версии пакетов и их состояния. После каждого обновления архива quinn-diff сравнивает список пакетов для целевой архитектуры со списком пакетов с исходным кодом и передаёт базе данных список пакетов, которые необходимо перекомпилировать; в базе данных они получают статус Needs-Build.
Все службы сборки (их может быть несколько) регулярно опрашивают базу данных о таких пакетах и выбирают некоторые из них, последние получают статус Building. Конечно, люди тоже могут выбирать пакеты, напр. в особых случаях, когда автоматическая компиляция невозможна. Здесь мы видим и вторую цель wanna-build: она гарантирует, что одна версия пакета не будет собрана дважды.
Если всё идёт хорошо, позже готовый пакет может быть загружен, что соответствует другому состоянию, Uploaded. После этого он будет установлен в архив Debian и появится в обновлённом списке пакетов для целевой архитектуры. Этот список будет объединён с базой данных, а пакет перейдёт в состояние Installed и останется в нём до тех пор, пока не появится следующая версия пакета с исходным кодом.
Имеются несколько других состояний; они включают в себя следующие: Failed для пакетов, которые не удалось собрать из-за ошибок в исходном коде, и ожидается, что эти ошибки будут исправлены в следующей версии (после сообщения о проблеме, конечно). Поэтому новая версия сразу же перейдёт в состояние Needs-Build, но с предупреждением о том, что что-то было не так с предыдущей версией. Вместе с этим состоянием сохраняется и описание ошибки. Состояние Dep-Wait используется, когда пакету для компиляции требуются некоторые другие пакеты, но они пока не доступны и должны быть собраны до этого пакета. Это состояние сохраняет список требуемых пакетов и, возможно, версий, и если все они будут установлены в архив, состояние исходного пакета снова изменится на Needs-Build.
Как мы уже видели, службы сборки выбирают пакеты из базы данных для компиляции. Рассмотрим это подробнее. Если в базе данных имеются некоторые пакеты, которые нужно собрать, для фактической компиляции используется sbuild, а каждый журнал сборки отправляется сопровождающему службы. Он просматривает журнал и решает, что делать с пакетом: загрузить его, установить ему состояние Failed или Dep-Wait и повторить сборку и т.д. Если получено положительное подтверждение (подписанный файл .changes), служба перемещает пакет в каталог загрузки, откуда все пакеты загружаются при помощи задачи cron.
Просмотр файлов журналов является единственным вмешательством человека в весь процесс сборки, если, конечно, не происходит ошибок. Имеются две причины того, чтобы больше не автоматизировать этот процесс. Во-первых, иногда сборки заканчиваются с результатом «OK», но сборка всё равно может завершиться неудачно по причинам, которые машина определить не может. А во-вторых, для загрузки напрямую потребовалось бы автоматически подписывать получившиеся файлы ключом без пароля на машине сборки. Мне это кажется недопустимой дырой в безопасности.
Сценарий сборки sbuild более или менее лишь вызывает некоторые стандартные инструменты Debian для компиляции исходного кода. Он также помогает некоторым общим задачам и ведению учёта с автоматической установкой зависимостей, необходимых для сборки, которые требуются собираемым пакетом.
Содержание разработано Романом Ходеком (Roman Hodek) для 6-ого международного Linux-конгресса 1999 года; оно было слегка обновлено Филиппом Керном (Philipp Kern) для отражения настоящего положения дел в 2009 году