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: @@
-[[Category:Devel]]
+{{DISPLAYTITLE:buildreq}}
-[[Category:Sisyphus]]
+<tt>'''buildreq'''</tt> — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете <tt>rpm-utils</tt>.
-{{Викифицировать}}
-{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/spectips/buildreq}}
-При написании spec-файла возникает необходимость указывать сборочные зависимости в теге BuildRequires. Для упрощения этого процесса в ALT Linux используется специальный скрипт, который называется '''buildreq''' и находится в пакете '''rpm-utils'''.
+Использование:
+ $ buildreq example.spec
-Использовать его просто:
+== Принцип действия ==
-<pre>$ buildreq example.spec</pre>
+<tt>buildreq</tt> производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает (с помощью <tt>strace(1)</tt>) все используемые пакеты и по окончанию сборки добавляет в спек тег <tt>BuildRequires</tt> с отслеженными сборочными зависимостями.
-Скрипт производит почти такую же работу, как и при сборке пакета. В процессе сборки программы он отслеживает все используемые пакеты и в результате добавляет в спек тег BuildRequires с нужными сборочными зависимостями.
+<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты).  При этом вследствие производимой оптимизации графа зависимостей со временем условие достаточности может нарушаться, тогда приходится повторно запускать {{cmd|buildreq}} и отслеживать, не пропало ли что нужное.
-Надо сказать, что скрипт не самый совершенный и иногда бывает, что зависимости не очень правильные -- они могут указывать на пакеты совсем не нужные при сборке. В таком случае, выявить и отсеять лишнее вам придется самостоятельно. Другими словами, buildreq производит лишь оценку сверху -- перечисляет ''достаточные'', но необязательно ''необходимые'' пакеты.
+Обратите внимание: {{cmd|buildreq}} помогает зафиксировать нужные сборочные зависимости, когда они '''уже''' найдены, установлены в сборочную среду, и сборка проходит успешно.
-Также, если в спеке уже прописан тег ''BuildRequires'', то после buildreq он будет удален. Чтобы этого не происходило вам следует использовать тег ''BuildPreReq''. Эти два тега равносильны и единственное отличие состоит в том, что второй не "затирается" при использовании buildreq.
+== Особенности использования ==
-По умолчанию, отслеживаются лишь зависимости для стадий %prep и %build. Это можно изменить ключом -b, указывающим стадию, после которой надо остановиться. Так, -bi указывает, что отслеживать надо стадии %prep, %build и %install.
+Добавленный <tt>buildreq</tt> тэг <tt>BuildRequires</tt> (опознаётся по непосредственно предшествующему комментарию «Automatically added by buildreq») затирается при следующих запусках <tt>buildreq</tt>. Равносильный тэг <tt>BuildPreReq</tt> не трогается — этим можно пользоваться в своих целях.
-<pre>Date: Tue, 18 Oct 2005 01:10:33 +0400
+По умолчанию отслеживаются лишь зависимости для стадий <tt>%prep</tt> и <tt>%build</tt>. Это можно изменить ключом <tt>-b</tt>, указывающим стадию, после которой надо остановиться. Так, <tt>-bi</tt> указывает, что отслеживать надо стадии <tt>%prep</tt>, <tt>%build</tt> и <tt>%install</tt>.
-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>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt>.
-> On Mon, Oct 17, 2005 at 11:23:38PM +0400, Dmitry V. Levin wrote:
-> > > И что с этим предлагается делать?
-> > Просто добавить apache-devel в список сборочных зависимостей.
-> М-да.  Даже мысли не допустил, что его там могло не быть...
-Это известная засада: buildreq "не ловит" файлы в /etc/rpm/macros.d.
+Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать {{cmd|buildreq -u}} (включено по умолчанию с 0.9.13-alt1 для документирования удаляемых из графа зависимостей на случай его изменения в последующем).
-Workaround: где-нибудь в этих макросах делать stat за пределы
-/etc/rpm/macros.d.  stat будет срабатывать только при раскрытии
-макросов.  В alternatives вроде такое было.</pre>
-<pre>> Интересно зачем для сборки нужен lint? Он там *действительно*
+== Известные ограничения ==
-> используется? telnet в списке тоже несколько смущает...
-Для более точного отслеживания нежелательных пакетов можно использовать
+=== <tt>.d</tt>-директории ===
-e.g. buildreq --trace-p=lclint --trace-p=telnet *.spec
-Полное название опций
+Пакеты, использующие <tt>.d</tt>-директории для расширения своей функциональности, могут столкнуться с проблемой избыточных зависимостей — <tt>buildreq</tt> «захватит» все пакеты, добавляющие файлы в <tt>.d</tt>-директорию (<tt>/etc/profile.d/mc.sh</tt>, к примеру, добавил бы зависимость на <tt>mc</tt> для всех пакетов вообще, поскольку соответствующий файл загружается при запуске shell).
---trace-package=PKG
---trace-file=FILE</pre>
-''[http://lists.altlinux.org/pipermail/devel/2008-March/071889.html at@ in devel@]''
-== Ссылки ==
+Для предотвращения этой ситуации в <tt>buildreq</tt> предусмотрены списки исключений, находящиеся в директории <tt>/etc/buildreqs/files/ignore.d</tt>. Пакету, предоставляющему <tt>.d</tt>-директорию, следует включить эту директорию в список исключений для <tt>buildreq</tt>.
-* [[Rpm/AutoReq]]
+В тех случаях, когда из пакета используется только файл, попадающий под игнорируемую маску (например, файл макросов в <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. Сборочные зависимости можно указывать какие угодно, лишь бы зафиксировать сборочную среду и чтобы пакет собирался. А установочные зависимости — это более тонкая материя: они, как правило, должны быть виртуальными, и их, как правило, не следует непосредственно указывать (вручную) вообще. Потому что сборочные зависимости относительно изолированы и независимы друг от друга, то есть по отношению к ним не предъявляется глобальных требований согласованности. А по отношению к установочным зависимостям глобальные требования согласованности гораздо сильнее.
+Это можно понимать так. При сборке каждого пакета разворачивается отдельная сборочная среда (чрут); и при сборке, например, двух пакетов
+обычно нет требований согласованности их сборочных чрутов. А при установке требования согласованности есть всегда; изолированной среды
+для установки не бывает.
+== Лицензия ==
+GPLv2 or later.
+== Исходный код ==
+[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]]