Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/incominger ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Incominger


Эта программа предназначена для проверки и пересборки приходящих в сизиф (или любой другой репозиторий).

Директории (config):


node_d – директория с конфигурацией пересборочных машин. Каждая пересборочная машина описывается одним файлом с расширением '.conf' в этой директории.
incoming_d – директория с конфигурацией инкомингов т.е. мест откуда нужно забирать новые (непроверенные) пакеты.
remote_scripts – в этой директории содержатся скрипты для работы на пересборочных машинах.
lock_dir – директория содержит блок-директории для пересобираемых пакетов.
syslock_dir – в этой директории блокируются пересборочные машины. Это может произойти из-за неустранимой ошибки.
logs_dir – директория предназначена для хранения логов.
accept_logdir – логи успешной пересборки.
reject_logdir – логи пакетов содержащих ошибки.
archive_logdir – директория для хранения архива логов.
reject_dir – отвергнутые пакеты.
srpms_dir – директория с не проверенными пакетами.
queue_dir – директория содержащая символические ссылки на пересобираемые в данный момент пакеты. Эта директория нужна только во время пересборки пакетов.
distrib_repository – внешний репозиторий относительно которого идет пересборка.
internal_repository – внутренний временный репозиторий. Он необходим для хранения новых пересобранных пакетов. Эта директория должна быть доступна для всех пересборочных машин.

Скрипты:


butcher – скрипт запускается для каждой пересборочной машины. Он отвечает за выполнение операций на удаленной стороне (на пересборочной машине). Эта программа запускается с двумя аргументами:


Для описания действий, которые необходимо выполнить на пересборочной машине используются профили. Это файлы в которых описываются определенные обработчики событий (функции). Эти обработчики вызываются в процессе работы butcher. Если в профиле какой-нибудь обработчик не реализован, то butcher просто пропускает его вызов.


rebuild – программа для пересборки пакетов. Ее задача – это формирование списка пакетов для пересборки и вызов butcher с нужными аргументами. Список пакетов формируется с помощью функций, описанных в файле queue_functions (см. ниже).
check – программа для параллельной проверки пакетов. Она подобна rebuild, но не строит очередь.
apt_cache – программа для поиска имен пакетов в кэше apt'a.
cleanup – простой скрипт для отчистки рабочей зоны от старых пакетов.
commit – программа переносит обработанные пакеты из внутреннего репозитория в accept_dir и reject_dir. Также она архивирует логи.
doomer – скрипт рассылающий письма «счастья».
get – программа проверяет инкоминги и забирает пакеты, которые необходимо проверить.

Алгоритмы:


Формирование списка пакетов для пересборки.
Сначала несколько утверждений:


Пример задачи: В директории Z находятся исходные пакеты sA, sB и sC. Исходный пакет sA требует бинарный пакет, который получится из исходного sB. Также sA требует файл, который будет предоставляться бинарным пакетом из sC. sB требует бинарный пакет Х, которого вообще нигде нет. Для полноты картины примем, что этих пакетов нет ни в одном из наших репозиториев (это совершенно новые пакеты).


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


Вот последовательность действий:


Если все бинарные пакеты у нас есть, то этот исходный можно пересобрать.
Но до начала сборки, стоит сделать еще одну проверку:

  • получаем имена исходных пакетов, из которых будут собраны бинарные пакеты, необходимые для сборки исследуемого исходного пакета. Проверяем, есть ли эти исходные пакеты среди не проверенных (в incoming). Если кто-то там есть, то тоже откладываем исследуемый исходный пакет([WAIT]). Если ожидаемый пакет не пересобирется, то он будет перемещен из директории с непроверенными пакетами и ожидать будет некого.

  • Эти шаги повторяются до тех пор, пока на очередной итерации не соберется ни один пакет. Это означает, что мы достигли «стабильного» состояния и оставшиеся пакеты нельзя собрать для этих репозиториев (внутреннего и внешнего).


    Минус такого алгоритма состоит в том, что мы не можем предвидеть ход сборки более чем на один шаг вперед.


    Ссылок на эту страницу нет


     
    Файлы [Скрыть файлы/форму]
    Комментариев нет. [Показать комментарии/форму]