ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Subject: Re: [devel] новые gear + hasher
Date: Wed, 7 May 2008 03:39:06 +0400
Message-ID: <20080506233906.GB17580@wo.int.altlinux.org> (raw)
In-Reply-To: <20080429191713.GA5463@atlas.home>

[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]

On Tue, Apr 29, 2008 at 11:17:13PM +0400, Sergey Vlasov wrote:
> 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) - достаточно обычной сборочной зависимости.

Ответ получился настолько развёрнутым, что просится в документацию.
Поэтому позволю себе его дополнить.

Действительно, при сборке srpm-пакетов вычисление и установка в чрут
сборочных зависимостей происходит ровно 1 раз, поскольку все сборочные
зависимости явно указаны в заголовке srpm-пакета.
При сборке из gear вычисление в чруте и установку сборочных зависимостей
в чрут приходится выполнять в 3 этапа:
1. извлечение зависимостей вида BuildRequires(pre) из spec-файла sed'ом и
их установка;
2. извлечение сборочных зависимостей из результата препроцессинга spec-файла
(rpmbuild -bE) и их установка;
3. создание srpm-пакета (rpmbuild -bs) и установка сборочных зависимостей
согласно заголовку srpm-пакета.

Таким образом, в BuildRequires(pre) необходимо указывать только такие
основополагающие сборочные зависимости, которые необходимы для корректного
вычисления сборочных зависимостей посредством rpmbuild -bE и rpmbuild -bs.

> > 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 эти пакеты были
> уже установлены.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

      parent reply	other threads:[~2008-05-06 23:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 10:13 Evgeny Sinelnikov
2008-04-29 10:17 ` Alexey Gladkov
2008-04-29 10:22   ` Evgeny Sinelnikov
2008-04-29 10:31     ` Alexey Gladkov
2008-04-29 10:48       ` Evgeny Sinelnikov
2008-04-29 10:51         ` Evgeny Sinelnikov
2008-04-29 13:05 ` Dmitry V. Levin
2008-04-29 13:22   ` Alexey Gladkov
2008-04-29 13:25     ` Dmitry V. Levin
2008-04-29 15:05       ` Evgeny Sinelnikov
2008-04-29 19:17         ` Sergey Vlasov
2008-04-29 19:21           ` Andrey Rahmatullin
2008-05-06 23:44             ` Dmitry V. Levin
2008-05-06 23:39           ` Dmitry V. Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080506233906.GB17580@wo.int.altlinux.org \
    --to=ldv@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git