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

Материал из ALT Linux Wiki
 
(не показано 14 промежуточных версий 6 участников)
Строка 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}} помогает зафиксировать нужные сборочные зависимости, когда они '''уже''' найдены, установлены в сборочную среду, и сборка проходит успешно.


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


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


По умолчанию отслеживаются лишь зависимости для стадий <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>.
 
Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать {{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>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]
[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]]

Текущая версия от 09: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)