Buildreq

buildreq — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете rpm-utils.

Использование:

$ buildreq example.spec

Принцип действия

buildreq производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает (с помощью strace(1)) все используемые пакеты и по окончанию сборки добавляет в спек тег BuildRequires с отслеженными сборочными зависимостями.

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

Другими словами, buildreq помогает зафиксировать нужные сборочные зависимости, когда они уже найдены, установлены в сборочную среду, и сборка проходит успешно.

Особенности использования

Добавленный buildreq тэг BuildRequires (опознаётся по непосредственно предшествующему комментарию «Automatically added by buildreq») затирается при следующих запусках buildreq. Равносильный тэг BuildPreReq не трогается — этим можно пользоваться в своих целях.

По умолчанию отслеживаются лишь зависимости для стадий %prep и %build. Это можно изменить ключом -b, указывающим стадию, после которой надо остановиться. Так, -bi указывает, что отслеживать надо стадии %prep, %build и %install.

Для трассировки упоминаний файла/пакета во время работы buildreq (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами --trace-file=FILE и --trace-package=PACKAGE.

Известные ограничения

.d-директории

Пакеты, использующие .d-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей — buildreq «захватит» все пакеты, добавляющие файлы в .d-директорию (/etc/profile.d/mc.sh, к примеру, добавил бы зависимость на mc для всех пакетов вообще, поскольку соответствующий файл загружается при запуске shell).

Для предотвращения этой ситуации в buildreq предусмотрены списки исключений, находящиеся в директории /etc/buildreqs/files/ignore.d. Пакету, предоставляющему .d-директорию, следует включить эту директорию в список исключений для buildreq.

В тех случаях, когда из пакета используется только файл, попадающий под игнорируемую маску (например, файл макросов в /etc/rpm/macros.d/), в игнорируемый файл необходимо добавить какой-нибудь код, который «трогает» (stat(2), access(2), open(2), execve(2)) другой, неигнорируемый, файл из того же пакета. Таким образом пакет войдёт в список зависимостей.

Пример workaround’а можно посмотреть в файле /etc/rpm/macros.d/alternatives, в макросе %_altdir.

Заметки на манжетах

Нужно понимать, что сборочные зависимости BuildRequires в некоторых отношениях принципиально отличаются от установочных зависимостей Requires. Сборочные зависимости можно указывать какие угодно, лишь бы зафиксировать сборочную среду и чтобы пакет собирался. А установочные зависимости — это более тонкая материя: они, как правило, должны быть виртуальными, и их, как правило, не следует непосредственно указывать (вручную) вообще. Потому что сборочные зависимости относительно изолированы и независимы друг от друга, то есть по отношению к ним не предъявляется глобальных требований согласованности. А по отношению к установочным зависимостям глобальные требования согласованности гораздо сильнее.

Это можно понимать так. При сборке каждого пакета разворачивается отдельная сборочная среда (чрут); и при сборке, например, двух пакетов обычно нет требований согласованности их сборочных чрутов. А при установке требования согласованности есть всегда; изолированной среды для установки не бывает.

Лицензия

GPLv2 or later.

Исходный код

rpm-utils.git