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

Версия от 08:56, 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

@@ Строка 21: / Строка 21: @@
 Для трассировки упоминаний файла/пакета во время работы <tt>buildreq</tt> (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами <tt>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt>).
-== Известные проблемы ==
+== Известные ограничения ==
-<pre>Date: Tue, 18 Oct 2005 01:10:33 +0400
+Пакеты, использующие <tt>.d</tt>-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей - <tt>buildreq</tt> "захватит" все пакеты, добавляющие файлы в <tt>.d</tt>-директорию (<tt>/etc/profile.d/mc.sh</tt>, к примеру, добавил бы зависимость на <tt>mc</tt> для всех пакетов вообще, поскольку соответствующий файл загружается при запуске shell).
-From: Alexey Tourbin <at@>
-To: ALT Devel discussion list <devel@>
-Subject: [devel] Re: webalizer-2.01.10-alt6
-On Mon, Oct 17, 2005 at 10:30:28PM +0300, Michael Shigorin wrote:
+Для предотвращения этой ситуации в <tt>buildreq</tt> предусмотрены списки исключений, находящиеся в директории <tt>/etc/buildreqs/files/ignore.d</tt>. Пакет, предоставляющий <tt>.d</tt>-директорию, обязан предоставить и соответствующий список исключений для <tt>buildreq</tt>.
-> On Mon, Oct 17, 2005 at 11:23:38PM +0400, Dmitry V. Levin wrote:
-> > > И что с этим предлагается делать?
-> > Просто добавить apache-devel в список сборочных зависимостей.
-> М-да.  Даже мысли не допустил, что его там могло не быть...
-Это известная засада: buildreq "не ловит" файлы в /etc/rpm/macros.d.
+В тех случаях, когда из пакета используется только файл, попадающий под игнорируемую маску (например, файл макросов в <tt>/etc/rpm/macros.d/</tt>), в игнорируемый файл добавить какой-нибудь код, который "трогает" (<tt>stat(2)</tt>, <tt>access(2)</tt>, <tt>open(2)</tt>, <tt>execve(2)</tt>) другой файл из того же пакета. Таким образом пакет войдёт в список зависимостей.
-Workaround: где-нибудь в этих макросах делать stat за пределы
-/etc/rpm/macros.d.  stat будет срабатывать только при раскрытии
+Пример workaround'а можно посмотреть в файле <tt>/etc/rpm/macros.d/alternatives</tt>, в макросе <tt>%_altdir</tt>.
-макросов.  В alternatives вроде такое было.</pre>
 == Лицензия ==