Buildreq: различия между версиями
| Строка 19: | Строка 19: | ||
По умолчанию отслеживаются лишь зависимости для стадий <tt>%prep</tt> и <tt>%build</tt>. Это можно изменить ключом <tt>-b</tt>, указывающим стадию, после которой надо остановиться. Так, <tt>-bi</tt> указывает, что отслеживать надо стадии <tt>%prep</tt>, <tt>%build</tt> и <tt>%install</tt>. | По умолчанию отслеживаются лишь зависимости для стадий <tt>%prep</tt> и <tt>%build</tt>. Это можно изменить ключом <tt>-b</tt>, указывающим стадию, после которой надо остановиться. Так, <tt>-bi</tt> указывает, что отслеживать надо стадии <tt>%prep</tt>, <tt>%build</tt> и <tt>%install</tt>. | ||
Для трассировки упоминаний файла/пакета во время работы <tt>buildreq</tt> (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами <tt>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt> | Для трассировки упоминаний файла/пакета во время работы <tt>buildreq</tt> (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами <tt>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt>. | ||
== Известные ограничения == | == Известные ограничения == | ||
Версия от 09:16, 21 августа 2008
buildreq — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете rpm-utils.
Использование:
$ buildreq example.spec
Принцип действия
buildreq производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает все используемые пакеты и по окончанию сборки добавляет в спек тег 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-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей - 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.