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>.
 Использование:
@@ Строка 9: / Строка 7: @@
 == Принцип действия ==
-<tt>buildreq</tt> производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает все используемые пакеты и по окончанию сборки добавляет в спек тег <tt>BuildRequires</tt> с отслеженными сборочными зависимостями.
+<tt>buildreq</tt> производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает (с помощью <tt>strace(1)</tt>) все используемые пакеты и по окончанию сборки добавляет в спек тег <tt>BuildRequires</tt> с отслеженными сборочными зависимостями.
-<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты). При этом <tt>buildreq</tt> не пропускает необходимые зависимости.
+<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты).  При этом вследствие производимой оптимизации графа зависимостей со временем условие достаточности может нарушаться, тогда приходится повторно запускать {{cmd|buildreq}} и отслеживать, не пропало ли что нужное.
+Обратите внимание: {{cmd|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>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>.
+Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать {{cmd|buildreq -u}} (включено по умолчанию с 0.9.13-alt1 для документирования удаляемых из графа зависимостей на случай его изменения в последующем).
 == Известные ограничения ==
-Пакеты, использующие <tt>.d</tt>-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей - <tt>buildreq</tt> "захватит" все пакеты, добавляющие файлы в <tt>.d</tt>-директорию (<tt>/etc/profile.d/mc.sh</tt>, к примеру, добавил бы зависимость на <tt>mc</tt> для всех пакетов вообще, поскольку соответствующий файл загружается при запуске shell).
+=== <tt>.d</tt>-директории ===
+Пакеты, использующие <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>/etc/rpm/macros.d/</tt>), в игнорируемый файл необходимо добавить какой-нибудь код, который "трогает" (<tt>stat(2)</tt>, <tt>access(2)</tt>, <tt>open(2)</tt>, <tt>execve(2)</tt>) другой, неигнорируемый, файл из того же пакета. Таким образом пакет войдёт в список зависимостей.
+В тех случаях, когда из пакета используется только файл, попадающий под игнорируемую маску (например, файл макросов в <tt>/etc/rpm/macros.d/</tt>), в игнорируемый файл необходимо добавить какой-нибудь код, который «трогает» (<tt>stat(2)</tt>, <tt>access(2)</tt>, <tt>open(2)</tt>, <tt>execve(2)</tt>) другой, неигнорируемый, файл из того же пакета. Таким образом пакет войдёт в список зависимостей.
+Пример workaround’а можно посмотреть в файле <tt>/etc/rpm/macros.d/alternatives</tt>, в макросе <tt>%_altdir</tt>.
+== [http://lists.altlinux.org/pipermail/devel/2009-August/173696.html Заметки на манжетах] ==
+Нужно понимать, что сборочные зависимости BuildRequires в некоторых отношениях принципиально отличаются от установочных зависимостей Requires. Сборочные зависимости можно указывать какие угодно, лишь бы зафиксировать сборочную среду и чтобы пакет собирался. А установочные зависимости — это более тонкая материя: они, как правило, должны быть виртуальными, и их, как правило, не следует непосредственно указывать (вручную) вообще. Потому что сборочные зависимости относительно изолированы и независимы друг от друга, то есть по отношению к ним не предъявляется глобальных требований согласованности. А по отношению к установочным зависимостям глобальные требования согласованности гораздо сильнее.
-Пример workaround'а можно посмотреть в файле <tt>/etc/rpm/macros.d/alternatives</tt>, в макросе <tt>%_altdir</tt>.
+Это можно понимать так. При сборке каждого пакета разворачивается отдельная сборочная среда (чрут); и при сборке, например, двух пакетов
+обычно нет требований согласованности их сборочных чрутов. А при установке требования согласованности есть всегда; изолированной среды
+для установки не бывает.
 == Лицензия ==
@@ Строка 36: / Строка 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]]