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 --]
prev 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