On Tue, Apr 29, 2008 at 07:05:05PM +0400, Evgeny Sinelnikov wrote: > Непонятно теперь две вещи... > 1) Я полагаю, что требование для BuildRequires(pre) теперь > ужесточается... то есть нужно патчить спеки... Так? Тогда каков > формальный критерий? Если в хешере оно всё равно собирается? не > собирается ведь только в хешере, запущенном из-под gear... Разница в том, что в традиционном варианте hasher получает на вход готовый src.rpm, в котором уже присутствуют готовые сборочные зависимости, а при запуске через gear изначально доступны только файлы с исходниками и текст spec-файла. В последнем случае для получения сборочных зависимостей необходимо выполнить разбор spec-файла средствами rpmbuild, однако результат этой операции в общем случае зависит и от среды, в которой запускается rpmbuild - в частности, для раскрытия некоторых макросов требуется наличие в сборочной среде определённых пакетов, без которых при попытке разбора spec-файла возникают ошибки, препятствующие извлечению из него информации о зависимостях. Для разрыва этого цикла и создан механизм BuildRequires(pre) - такие зависимости извлекаются из spec-файла при помощи sed, и установки полученного из этих строк набора пакетов должно быть достаточно для выполнения команды вида: rpmbuild -bs --nodeps --define '_allow_undefined_macros 1' \ (определения _specdir и прочих каталогов) \ FILE.spec Формальный критерий необходимости BuildRequires(pre) - невозможность успешного выполнения указанной команды в сборочном чруте без предварительной установки туда некоторых пакетов, не входящих в минимальную сборочную систему. Обычно встречающиеся случаи, когда требуется BuildRequires(pre): 1) Использование макросов для формирования условных конструкций (например, упоминавшийся здесь макрос %_K_if_ver_gt - он раскрывается в %if, и при отсутствии определения макроса в сборочной среде встречающиеся далее %else или %endif рассматриваются как синтаксическая ошибка). 2) Использование макросов для подстановки версий в зависимости (типа Requires: PACKAGE >= %{get_version PACKAGE}) - обычно при отсутствии указанного пакета в сборочной среде такие макросы раскрываются в пустую строку, в результате формируется синтаксически неверный параметр тега Requires. В других случаях (если используется макрос без параметров, определённый в пакете, который оказался не установлен) в поле версии пакета попадает символ '%' из нераскрывшегося макроса, что rpmbuild также считает ошибкой. Если отсутствие определения макроса вызывает только предупреждения, но не приводит к ошибкам при разборе spec-файла для rpmbuild -bs, пакет, требуемый для такого макроса, не требуется указывать в BuildRequires(pre) - достаточно обычной сборочной зависимости. > 2) Довольно непонятно, почему, при наличии нужных BuildRequires(pre), > возникает это: > > ... > <13>Apr 29 14:39:11 rpmi: kde-common-devel-4.0.3-alt1 installed > error: line 44: Version required: Requires: libart_lgpl >= > - Hide quoted text - > hsh-rebuild: pkg.tar: failed to fetch build dependencies. > > На самом деле конструкция вида: > Requires: libart_lgpl >= %{get_version libart_lgpl} > на сборку влиять не должна... > но на новых gear + hasher оно так себя ведёт... Макрос %{get_version PACKAGE} может быть правильно раскрыт только при наличии в сборочной среде установленного пакета PACKAGE; если такой пакет не установлен, в результате раскрытия макроса получается пустая строка, которая при подстановке в spec-файл даёт синтаксическую ошибку. Из-за этого пакеты, упоминаемые в %{get_version ...} и других подобных макросах, необходимо также перечислять в BuildRequires(pre), чтобы к моменту разбора spec-файла средствами rpmbuild эти пакеты были уже установлены.