Buildreq: различия между версиями

Версия от 09:08, 21 августа 2008

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

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

$ buildreq example.spec

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

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

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

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

buildreq затирает уже имеющийся тэг BuildRequires, но не трогает равносильный ему тэг BuildPreReq — этим можно пользоваться в своих целях.

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

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

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

Пакеты, использующие .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.

Лицензия

GPLv2 or later.

Исходный код

rpm-utils.git

@@ Строка 25: / Строка 25: @@
 Пакеты, использующие <tt>.d</tt>-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей - <tt>buildreq</tt> "захватит" все пакеты, добавляющие файлы в <tt>.d</tt>-директорию (<tt>/etc/profile.d/mc.sh</tt>, к примеру, добавил бы зависимость на <tt>mc</tt> для всех пакетов вообще, поскольку соответствующий файл загружается при запуске shell).
-Для предотвращения этой ситуации в <tt>buildreq</tt> предусмотрены списки исключений, находящиеся в директории <tt>/etc/buildreqs/files/ignore.d</tt>. Пакет, предоставляющий <tt>.d</tt>-директорию, обязан предоставить и соответствующий список исключений для <tt>buildreq</tt>.
+Для предотвращения этой ситуации в <tt>buildreq</tt> предусмотрены списки исключений, находящиеся в директории <tt>/etc/buildreqs/files/ignore.d</tt>. Пакету, предоставляющему <tt>.d</tt>-директорию, следует включить эту директорию в список исключений для <tt>buildreq</tt>.
 В тех случаях, когда из пакета используется только файл, попадающий под игнорируемую маску (например, файл макросов в <tt>/etc/rpm/macros.d/</tt>), в игнорируемый файл необходимо добавить какой-нибудь код, который "трогает" (<tt>stat(2)</tt>, <tt>access(2)</tt>, <tt>open(2)</tt>, <tt>execve(2)</tt>) другой, неигнорируемый, файл из того же пакета. Таким образом пакет войдёт в список зависимостей.