[devel] Персональная собиралка Сизифа

[Evgeny Sinelnikov]

2008/5/7 Dmitry V. Levin <ldv на altlinux.org>:
> On Wed, May 07, 2008 at 02:40:16AM +0400, Wartan Hachaturow wrote:
>  > 2008/5/7 Alexey Gladkov <legion на altlinux.ru>:
>  > >  Раз это не сложно, то расскажи как узнать из какого git репозитория
>  > > собирасется пакет FooBar, при условии что из одного репозитория может
>  > > собираться не один пакет и то что имена пакетов и репозиториев не всегда
>  > > совпадают. Меня интересует альгритм поиска соотвествия. Я такого альгоритма
>  > > придумать не могу.
>  >

Я сейчас как раз нахожусь на стадии формализации процесса сборки
пакетов. При этом я ввёл ряд ограничений... Прежде всего это относится
к переходу от использования src.rpm-пакетов, в качестве первичного
источника, к gear-репозиториям. То есть сборка свалки из
src.rpm-пакетов сводится к предварительному импортированию этих
пакетов в git. Благо git.alt/archive делается путём gear-srpmimport...
При этом отпадает необходимость в излишней эвристике. Насчёт git
задано одно ограничение - сборка учитывает не теги, а выбранную
ветку... её обновление - означает необходимость пересобрать пакет.

Собиралка предполагает использовать gear --hasher для замыкания
сборочной среды, на выбранном репозитории. Особенность gear по сборке
src.rpm-пакета в chroot'е является здесь существенным моментом, хотя
это и приводит в к тому, что BuildRequires(pre) начинает требоваться
то там, то тут...

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

Для бинарных пакетов предполагается, что результат сборки является не
только функцией исходного пакета, но и того набора бинарных пакетов,
на котором собирается исходный. Поэтому при сборке всегда добавляется
номер сборки %release.bld1, %release.bld2, ... Это унифицирует процесс
пересборки...

В общем пока это только стадия формализации процесса сборки пакетов,
которая доведена, до необходимого минимума.

Скрипт называется autobuilder:
http://git.etersoft.ru/people/sin/packages/geet-autobuilder.git
Но он пока далёк от совершенства... К сожалению он настолько сырой,
что использовать его пока можно только для фиксированного набора
задач... Проблема также состоит в том, что многие пакеты не содержат
правильных зависимостей BuildRequires(pre), которые могут
потребоваться не только для вычисления nvr, но и, например, для
раскрытия макросов вида %get_version, указанных в зависимостях.

В этом плане меня интересует вопрос, существуют ли средства для
вычисления порядка сборки пакетов, если необходимо собрать несколько
взаимозависимых пакета? Как при этом принято поступать?

Кстати, наткнулся на то, что в kdelibs есть race на уровне генерации
заголовочных файлов и, в стандартной схеме сборки на многопроцессорной
или многоядерной машине. Поэтому этот пакет может собираться
"иногда"...

>  > У вас в rpm-мире вообще никогда ничего нельзя понять точно -- даже то,
>  > где кончается имя пакета и начинается версия по имени файла ;) Это я
>  > уже осознал.
>
>  В версии, релизе и архитектуре пакета не может быть дефисов, так что, если
>  имя файла пакета каноническое (не было переименовано для запутывания
>  следов), то имя, версию, релиз и архиткутуру пакета можно идентифицировать
>  однозначно по имени файла пакета.
>

Для этого можно, например, относительно легко воспользоваться
python-modules-rpm, который умеет парсить заголовки пакетов.

>
>  > Поскольку в данном случае речь идёт только об src.rpm'ах, то
>  > однозначное отображение между репозиторием и src.rpm установить можно,
>  > я полагаю.
>
>  В 90% случаев (число взято с потолка, но ситуацию отражает) можно.
>

-- 
Sin (Sinelnikov Evgeny)