Buildreq: различия между версиями
("why buildreq") |
м (→Особенности использования: -u по умолчанию) |
||
| (не показаны 24 промежуточные версии 6 участников) | |||
| Строка 1: | Строка 1: | ||
{{DISPLAYTITLE:buildreq}} | |||
{{ | <tt>'''buildreq'''</tt> — утилита для автоматизированного поиска сборочных зависимостей пакетов. Находится в пакете <tt>rpm-utils</tt>. | ||
Использование: | |||
$ buildreq example.spec | |||
== Принцип действия == | |||
< | <tt>buildreq</tt> производит почти такую же работу, как и при обычной сборке пакета. В процессе сборки программы он отслеживает (с помощью <tt>strace(1)</tt>) все используемые пакеты и по окончанию сборки добавляет в спек тег <tt>BuildRequires</tt> с отслеженными сборочными зависимостями. | ||
<tt>buildreq</tt> не обладает искусственным интеллектом, и поэтому может ошибаться в «большую» сторону, добавляя в зависимости ненужные пакеты (результатом работы являются ''достаточные'', но не ''необходимые'' пакеты). При этом вследствие производимой оптимизации графа зависимостей со временем условие достаточности может нарушаться, тогда приходится повторно запускать {{cmd|buildreq}} и отслеживать, не пропало ли что нужное. | |||
Обратите внимание: {{cmd|buildreq}} помогает зафиксировать нужные сборочные зависимости, когда они '''уже''' найдены, установлены в сборочную среду, и сборка проходит успешно. | |||
== Особенности использования == | |||
Добавленный <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>buildreq</tt> (например, для определения того, почему какой-то пакет оказывается в сборочных зависимостях) можно пользоваться ключами <tt>--trace-file=FILE</tt> и <tt>--trace-package=PACKAGE</tt>. | |||
> | |||
> > > | |||
> | |||
Для сохранения неоптимизированных (полных) сборочных зависимостей комментарием в спек-файле можно использовать {{cmd|buildreq -u}} (включено по умолчанию с 0.9.13-alt1 для документирования удаляемых из графа зависимостей на случай его изменения в последующем). | |||
== Известные ограничения == | |||
=== <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>) другой, неигнорируемый, файл из того же пакета. Таким образом пакет войдёт в список зависимостей. | |||
> | |||
> > | |||
> > | |||
> | |||
> | |||
> | |||
> | |||
Пример 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]] | |||
Текущая версия от 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.
Исходный код
См. тж.
- buildreq-src (пакет perl-RPM-Source-Dependency-Analyzer)