[devel] новые gear + hasher

[Sergey Vlasov]

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 эти пакеты были
уже установлены.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080429/17fcc3d8/attachment-0002.bin>