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

Текущая версия от 12:54, 2 января 2017

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

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

$ buildreq example.spec

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

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

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

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

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

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

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

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

Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать buildreq -u (включено по умолчанию с 0.9.13-alt1 для документирования удаляемых из графа зависимостей на случай его изменения в последующем).

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

`.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

См. тж.

buildreq-src (пакет perl-RPM-Source-Dependency-Analyzer)

@@ Строка 1: / Строка 1: @@
-__NOTOC__
 {{DISPLAYTITLE:buildreq}}
-[[Категория:Devel]]
+<tt>'''buildreq'''</tt> — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете <tt>rpm-utils</tt>.
-[[Категория:Sisyphus]]
-<tt>buildreq</tt> — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете <tt>rpm-utils</tt>.
 Использование:
@@ Строка 12: / Строка 9: @@
 <tt>buildreq</tt> производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает (с помощью <tt>strace(1)</tt>) все используемые пакеты и по окончанию сборки добавляет в спек тег <tt>BuildRequires</tt> с отслеженными сборочными зависимостями.
-<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты).
+<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты).  При этом вследствие производимой оптимизации графа зависимостей со временем условие достаточности может нарушаться, тогда приходится повторно запускать {{cmd|buildreq}} и отслеживать, не пропало ли что нужное.
+Обратите внимание: {{cmd|buildreq}} помогает зафиксировать нужные сборочные зависимости, когда они '''уже''' найдены, установлены в сборочную среду, и сборка проходит успешно.
 == Особенности использования ==
@@ Строка 21: / Строка 20: @@
 Для трассировки упоминаний файла/пакета во время работы <tt>buildreq</tt> (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами <tt>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt>.
+Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать {{cmd|buildreq -u}} (включено по умолчанию с 0.9.13-alt1 для документирования удаляемых из графа зависимостей на случай его изменения в последующем).
 == Известные ограничения ==
@@ Строка 33: / Строка 34: @@
 Пример workaround’а можно посмотреть в файле <tt>/etc/rpm/macros.d/alternatives</tt>, в макросе <tt>%_altdir</tt>.
+== [http://lists.altlinux.org/pipermail/devel/2009-August/173696.html Заметки на манжетах] ==
+Нужно понимать, что сборочные зависимости BuildRequires в некоторых отношениях принципиально отличаются от установочных зависимостей Requires. Сборочные зависимости можно указывать какие угодно, лишь бы зафиксировать сборочную среду и чтобы пакет собирался. А установочные зависимости — это более тонкая материя: они, как правило, должны быть виртуальными, и их, как правило, не следует непосредственно указывать (вручную) вообще. Потому что сборочные зависимости относительно изолированы и независимы друг от друга, то есть по отношению к ним не предъявляется глобальных требований согласованности. А по отношению к установочным зависимостям глобальные требования согласованности гораздо сильнее.
+Это можно понимать так. При сборке каждого пакета разворачивается отдельная сборочная среда (чрут); и при сборке, например, двух пакетов
+обычно нет требований согласованности их сборочных чрутов. А при установке требования согласованности есть всегда; изолированной среды
+для установки не бывает.
 == Лицензия ==
@@ Строка 39: / Строка 47: @@
 == Исходный код ==
 [http://git.altlinux.org/people/ldv/packages/rpm-utils.git rpm-utils.git]
+== См. тж. ==
+* [https://lists.altlinux.org/pipermail/devel/2016-March/201093.html buildreq-src] (пакет {{pkg|perl-RPM-Source-Dependency-Analyzer}})
+[[Категория:Utils]]