[devel] Проблема с hasher

[devel] Проблема с hasher

[Vadim V. Zhytnikov]

Добрый день!

Пытаясь заточить пакет maxima под x86_64
столкнулся со странной проблемой.

Дело в том, что из этого пакета собирается
несколько бинарных пакетов с разными
версиями Common Lisp и состав бинарных пакетов
различен для 32bit и 64bit.  Для i586 maxima
собирается с gcl, clisp и sbcl, а вот на x86_64
только с gcl и clisp (собрать sbcl под x86_64 пока
не удалось).  Поэтому в начале спека есть
конструкция

%ifarch %ix86
%define BUILD_GCL	1
%define BUILD_CLISP 	1
%define BUILD_SBCL	1
%define BUILD_CMUCL	0
%else
%define BUILD_GCL	1
%define BUILD_CLISP 	1
%define BUILD_SBCL	0
%define BUILD_CMUCL	0
%endif

ну и далее всё относящееся
к каждому бинарному пакету обвешано
%if %BUILD_<XYZ> %endif

При ручной сборке как в i586 так и в x86_64
всё отрабатывает совершенно нормально.
Получаем три пакета для i586 и два x86_86.

Но вот при сборке в hasher на x86_64 hsh
пытается поствить sbcl, которого там нет.

Что делать?

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] Проблема с hasher

[Dmitry V. Levin]

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

On Sat, Nov 12, 2005 at 02:03:20PM +0300, Vadim V. Zhytnikov wrote:
[...]
> ну и далее всё относящееся
> к каждому бинарному пакету обвешано
> %if %BUILD_<XYZ> %endif

В том числе и сборочные зависимости?

> При ручной сборке как в i586 так и в x86_64
> всё отрабатывает совершенно нормально.
> Получаем три пакета для i586 и два x86_86.
> 
> Но вот при сборке в hasher на x86_64 hsh
> пытается поствить sbcl, которого там нет.
> 
> Что делать?

hsh --query-repackage


-- 
ldv

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

Re: [devel] Проблема с hasher

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:
>>ну и далее всё относящееся
>>к каждому бинарному пакету обвешано
>>%if %BUILD_<XYZ> %endif
> 
> 
> В том числе и сборочные зависимости?
> 
Да.  А то как бы у меня проходил rpm -b
на x86_64 ?  Нет там sbcl.rpm

>>Что делать?
> 
> 
> hsh --query-repackage
> 

Так сработало!

Теперь другой вопрос - а incominger использует
этот ключ или нет?  Что мне класть в incoming?


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] Проблема с hasher

[php-coder]

--- Vadim V. Zhytnikov 2005-11-12 14:03:20 +0300
+++ php-coder 2005-11-12 20:27:35 +0600

VVZ> %ifarch %ix86
VVZ> %define BUILD_GCL	1
VVZ> %define BUILD_CLISP 	1
VVZ> %define BUILD_SBCL	1
VVZ> %define BUILD_CMUCL	0
VVZ> %else
VVZ> %define BUILD_GCL	1
VVZ> %define BUILD_CLISP 	1
VVZ> %define BUILD_SBCL	0
VVZ> %define BUILD_CMUCL	0
VVZ> %endif

    Я вот взглянул на это и сразу подумал: если меняется только
    BUILD_SBCL, то зачем такое условие? Так было бы проще:

    %define BUILD_GCL   1
    %define BUILD_CLISP 1
    %define BUILD_CMUCL 0

    %ifarch %ix86
      %define BUILD_SBCL 1
    %else
      %define BUILD_SBCL 0
    %endif


-- 
+ php-coder
+ php-coder[at]altlinux[dot]ru

Re: [devel] Проблема с hasher

[Vadim V. Zhytnikov]

php-coder пишет:
> --- Vadim V. Zhytnikov 2005-11-12 14:03:20 +0300
> +++ php-coder 2005-11-12 20:27:35 +0600
> 
> VVZ> %ifarch %ix86
> VVZ> %define BUILD_GCL	1
> VVZ> %define BUILD_CLISP 	1
> VVZ> %define BUILD_SBCL	1
> VVZ> %define BUILD_CMUCL	0
> VVZ> %else
> VVZ> %define BUILD_GCL	1
> VVZ> %define BUILD_CLISP 	1
> VVZ> %define BUILD_SBCL	0
> VVZ> %define BUILD_CMUCL	0
> VVZ> %endif
> 
>     Я вот взглянул на это и сразу подумал: если меняется только
>     BUILD_SBCL, то зачем такое условие? Так было бы проще:
> 
>     %define BUILD_GCL   1
>     %define BUILD_CLISP 1
>     %define BUILD_CMUCL 0
> 
>     %ifarch %ix86
>       %define BUILD_SBCL 1
>     %else
>       %define BUILD_SBCL 0
>     %endif
> 
> 
1. Различия 32 и 64 сброк могут быть не только
для sbcl.

2. Конструкция
%define BUILD_GCL	1
%define BUILD_CLISP 	1
%define BUILD_SBCL	1
%define BUILD_CMUCL	0
существует в этом спеке уже давно.  Выбрав нужные
0 или 1 я собираю только, что мне нужно в данный
момент.


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

[devel] Re: Проблема с hasher

[Michael Shigorin]

On Sat, Nov 12, 2005 at 02:03:20PM +0300, Vadim V. Zhytnikov wrote:
> Но вот при сборке в hasher на x86_64 hsh пытается поствить
> sbcl, которого там нет.  Что делать?

Обернуть соотв. BuildRequires %ifdef'ами?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Проблема с hasher

[Vadim V. Zhytnikov]

Michael Shigorin пишет:
> On Sat, Nov 12, 2005 at 02:03:20PM +0300, Vadim V. Zhytnikov wrote:
> 
>>Но вот при сборке в hasher на x86_64 hsh пытается поствить
>>sbcl, которого там нет.  Что делать?
> 
> 
> Обернуть соотв. BuildRequires %ifdef'ами?
> 
Так в том-то и прикол, что всё обёрнуто.
Я же написал, что при ручном repm -ba на
x86_64 пакет собирается.  Каким образом это
могло-бы случиться если бы был необёрнутый
неудовлетворённый BuildRequires?

Вот выяснилось, что ключик hsh --query-repackage
спасает положение ...

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] Re: Проблема с hasher

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 12:36:24AM +0300, Vadim V. Zhytnikov wrote:
> Michael Shigorin пишет:
> >On Sat, Nov 12, 2005 at 02:03:20PM +0300, Vadim V. Zhytnikov wrote:
> >
> >>Но вот при сборке в hasher на x86_64 hsh пытается поствить
> >>sbcl, которого там нет.  Что делать?
> >
> >Обернуть соотв. BuildRequires %ifdef'ами?
> >
> Так в том-то и прикол, что всё обёрнуто.
> Я же написал, что при ручном repm -ba на
> x86_64 пакет собирается.  Каким образом это
> могло-бы случиться если бы был необёрнутый
> неудовлетворённый BuildRequires?
> 
> Вот выяснилось, что ключик hsh --query-repackage
> спасает положение ...

Этот ключик для этих целей и был сделан.  Я так пакет gcc3.4
собираю на x86_64 (поскольку x86 пока ещё является базовой).

Использует ли --query-repackage incominger, я не в курсе.


-- 
ldv

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

Re: [devel] Re: Проблема с hasher

[Alexey Gladkov]

Michael Shigorin пишет:
> Обернуть соотв. BuildRequires %ifdef'ами?

Этого делать нельзя. У такого пакета могут быть проблемы с incoming/.

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 01:09:41AM +0300, Alexey Gladkov wrote:
> Michael Shigorin пишет:
> > Обернуть соотв. BuildRequires %ifdef'ами?
> 
> Этого делать нельзя. У такого пакета могут быть проблемы с incoming/.

Почему нельзя?
Разве комплектация пакетов не может быть архитектурно-зависимой?
Как же мне тогда собирать gcc3.4?


-- 
ldv

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

Re: [devel] Проблема с incominger

[Mikhail Zabaluev]

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

В Пнд, 14/11/2005 в 01:57 +0300, Dmitry V. Levin пишет:
> On Mon, Nov 14, 2005 at 01:09:41AM +0300, Alexey Gladkov wrote:
> > Michael Shigorin пишет:
> > > Обернуть соотв. BuildRequires %ifdef'ами?
> > 
> > Этого делать нельзя. У такого пакета могут быть проблемы с incoming/.
> 
> Почему нельзя?
> Разве комплектация пакетов не может быть архитектурно-зависимой?

src.rpm не должен быть архитектурно-зависимым (меняться в зависимости от
архитектуры сборки).

> Как же мне тогда собирать gcc3.4?

В чем там проблема?


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 02:47:52AM +0300, Mikhail Zabaluev wrote:
> В Пнд, 14/11/2005 в 01:57 +0300, Dmitry V. Levin пишет:
> > On Mon, Nov 14, 2005 at 01:09:41AM +0300, Alexey Gladkov wrote:
> > > Michael Shigorin пишет:
> > > > Обернуть соотв. BuildRequires %ifdef'ами?
> > > 
> > > Этого делать нельзя. У такого пакета могут быть проблемы с incoming/.
> > 
> > Почему нельзя?
> > Разве комплектация пакетов не может быть архитектурно-зависимой?
> 
> src.rpm не должен быть архитектурно-зависимым (меняться в зависимости от
> архитектуры сборки).

Почему?  src.rpm вообще не обязан существовать.
Очень неудобное изобретение, должен вам заметить.

> > Как же мне тогда собирать gcc3.4?
> 
> В чем там проблема?

Там нет проблем, просто для x86_64 сборка gnat выключена.


-- 
ldv

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

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:
> 
> Почему?  src.rpm вообще не обязан существовать.

Давай от него откажемся.

> Очень неудобное изобретение, должен вам заметить.

Согласен.

> Там нет проблем, просто для x86_64 сборка gnat выключена.

Тогда придётся сделать два разных исходных пакета gcc3.4 и gcc3.4.64bit .

Прецедент уже есть:
$ ls -1 Sisyphus/files/SRPMS/gqview-2.0.*
Sisyphus/files/SRPMS/gqview-2.0.0-alt1.64bit.src.rpm
Sisyphus/files/SRPMS/gqview-2.0.1-alt1.src.rpm

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 03:16:23AM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > 
> > Почему?  src.rpm вообще не обязан существовать.
> 
> Давай от него откажемся.

Я понемногу думаю в эту сторону.
Когда будет нормальный репозиторий исходников, надобность в src.rpm
пропадёт.

> > Очень неудобное изобретение, должен вам заметить.
> 
> Согласен.

Тогда надо работать над избавлением от него.

> > Там нет проблем, просто для x86_64 сборка gnat выключена.
> 
> Тогда придётся сделать два разных исходных пакета gcc3.4 и gcc3.4.64bit .

Нет, спасибо, это очень неудобно и чревато проблемами.

> Прецедент уже есть:
> $ ls -1 Sisyphus/files/SRPMS/gqview-2.0.*
> Sisyphus/files/SRPMS/gqview-2.0.0-alt1.64bit.src.rpm
> Sisyphus/files/SRPMS/gqview-2.0.1-alt1.src.rpm

Вот и с этими прецедентами надо бороться.


-- 
ldv

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

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Я понемногу думаю в эту сторону.

Не только ты :)

> Когда будет нормальный репозиторий исходников, надобность в src.rpm
> пропадёт.

Угу. Благородная цель.
Нужно обсудить структуру и на чем будем её реализовывать.

> Тогда надо работать над избавлением от него.

Да. Для начала.
Но у меня есть уже список что стоит ещё выкинуть. Но об этом чуть позже.

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Alexey Borovskoy]

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

* Понедельник 14 Ноябрь 2005 12:23 Dmitry V. Levin

> On Mon, Nov 14, 2005 at 03:16:23AM +0300, Alexey Gladkov wrote:
> > Dmitry V. Levin пишет:
> > > Почему?  src.rpm вообще не обязан существовать.
> >
> > Давай от него откажемся.
>
> Я понемногу думаю в эту сторону.
> Когда будет нормальный репозиторий исходников, надобность в
> src.rpm пропадёт.

А как хранение исходников реализовано в Gentoo?

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

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

Re: [devel] Проблема с incominger

[Mikhail Zabaluev]

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

В Пнд, 14/11/2005 в 03:03 +0300, Dmitry V. Levin пишет:
> > > Как же мне тогда собирать gcc3.4?
> > 
> > В чем там проблема?
> 
> Там нет проблем, просто для x86_64 сборка gnat выключена.

Какие различия в BuildRequires для gcc3.4 это вызывает?


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 03:49:43AM +0300, Mikhail Zabaluev wrote:
> В Пнд, 14/11/2005 в 03:03 +0300, Dmitry V. Levin пишет:
> > > > Как же мне тогда собирать gcc3.4?
> > > 
> > > В чем там проблема?
> > 
> > Там нет проблем, просто для x86_64 сборка gnat выключена.
> 
> Какие различия в BuildRequires для gcc3.4 это вызывает?

%ifarch %ix86
%def_with ada
%else
%def_without ada
%endif
[...]
%{?_with_ada:BuildPreReq: gcc%gcc_branch-gnat}

На x86_64 gcc3.4-gnat просто не собран.


-- 
ldv

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

Re: [devel] Проблема с incominger

[Anton D. Kachalov]

On Mon, Nov 14, 2005 at 03:59:04AM +0300, Dmitry V. Levin wrote:
> %ifarch %ix86
> %def_with ada
> %else
> %def_without ada
> %endif
> [...]
> %{?_with_ada:BuildPreReq: gcc%gcc_branch-gnat}
> 
> На x86_64 gcc3.4-gnat просто не собран.
Кстати, надо найти в себе сил и захачить это :) Проще всего взять уже
готовый gcc-gnat под x86_64 где-нить и пересобрать ими наш gnat. А потом
получившимся gnat'ом пересобрать ещё раз gnat и выкладывать в Cизиф :)

--
mouse

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Почему нельзя?
> Разве комплектация пакетов не может быть архитектурно-зависимой?
> Как же мне тогда собирать gcc3.4?

Потому что когда исходный пакет собирается, то в хедеры попадают не
все зависимости, а только те которые требуются для текущей платформы
(под которой идёт сборка).

Как получить BuildRequires для другой платформы ?
Ответ: переупаковать исходный пакет под другой архитектурой. А для
этого нужно создать полное окружение т.е. установить в систему всё что
нужно для сборки.
А как это сделать ?
Ответ: поставить в hasher все пакеты, указанные в BuildRequires. Но
ведь именно их мы и хотим узнать.

Даже если мы решим эту проблему встаёт следующий вопрос: исходные
пакеты под какую архитектуру держать в files/SRPMS ?

(Я говорил об на конференции)

В общем, нужно придумать способ узнать какие зависимости нужны для
каждой архитектуры без перепаковки самого пакета.

Анализ не предлагать.

В самом начале появления x86_64 мы с mouse@ думали над этой проблемой
и пришли к выводу, что проще не использовать условные блоки для
Buirequires.

Пока эта проблема не решена, брать в условные операторы Buirequires
нельзя.

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 03:02:01AM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > Почему нельзя?
> > Разве комплектация пакетов не может быть архитектурно-зависимой?
> > Как же мне тогда собирать gcc3.4?
> 
> Потому что когда исходный пакет собирается, то в хедеры попадают не
> все зависимости, а только те которые требуются для текущей платформы
> (под которой идёт сборка).
> 
> Как получить BuildRequires для другой платформы ?
> Ответ: переупаковать исходный пакет под другой архитектурой. А для

Это в общем случае.  В реальности достаточно использовать
--query-repackage.

[...]
> Пока эта проблема не решена, брать в условные операторы Buirequires
> нельзя.

Поскольку это касается меня лично, то я не согласен с этим ограничением,
ибо оно сразу сделает сборку некоторых пакетов (в т.ч. gcc) под x86_64
невозможной.

Дело в том, что далеко не каждый имеет возможность собирать пакеты прямо
в Сизиф минуя incominger с его неестественными ограничениями.


-- 
ldv

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

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:

Сейчас incominger считает что все исходные пакеты архитектурно-независимы.

> Это в общем случае.  В реальности достаточно использовать
> --query-repackage.

Хорошо. Я могу добавить поддержку --query-repackage. Правда тогда
incoming будет тормозить ещё сильнее т.к. для каждого исходного пакета
под каждую отличную от сборочной платформу будет делаться перепаковка
с --query-repackage. Потому что из исходного пакета нельзя понять есть
ли в нём архитектурно-зависимые зависимости или нет.

Но ты не ответил на следующий вопрос: какой исходный пакет класть в
files/SRPMS ?

Не у всех есть hasher и что еще более важно не у всех есть локальный
Сизиф для того чтобы переупаковать пакет с --query-repackage для своей
платформы.

> Дело в том, что далеко не каждый имеет возможность собирать пакеты прямо
> в Сизиф минуя incominger с его неестественными ограничениями.

Ограничения меняются в соответствии с желаниями мантейнеров. Раньше
никому в голову не приходило делать srpm архитектурно-зависимыми. С
первым неестественным желанием появится и поддержка.

Это новое условие не ложится в текущую схему работы incominger. Мне
садиться за перепланирование incominger для добавления этой суперфичи ?

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Dmitry V. Levin]

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

On Mon, Nov 14, 2005 at 03:46:43AM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> 
> Сейчас incominger считает что все исходные пакеты архитектурно-независимы.

В каком-то смысле они такие и есть (если посмотреть на payload).

> > Это в общем случае.  В реальности достаточно использовать
> > --query-repackage.
> 
> Хорошо. Я могу добавить поддержку --query-repackage. Правда тогда
> incoming будет тормозить ещё сильнее т.к. для каждого исходного пакета
> под каждую отличную от сборочной платформу будет делаться перепаковка
> с --query-repackage. Потому что из исходного пакета нельзя понять есть
> ли в нём архитектурно-зависимые зависимости или нет.

Можно попробовать соптимизировать, применяя --query-repackage только
тогда, когда иначе пакет не собирается из-за неудовлетворённых сборочных
зависимостей.

> Но ты не ответил на следующий вопрос: какой исходный пакет класть в
> files/SRPMS ?

Тот, который подписал и выложил мантейнер.

> Не у всех есть hasher и что еще более важно не у всех есть локальный
> Сизиф для того чтобы переупаковать пакет с --query-repackage для своей
> платформы.

У кого нет hasher'а, у того нет проблемы как таковой.

> > Дело в том, что далеко не каждый имеет возможность собирать пакеты прямо
> > в Сизиф минуя incominger с его неестественными ограничениями.
> 
> Ограничения меняются в соответствии с желаниями мантейнеров. Раньше
> никому в голову не приходило делать srpm архитектурно-зависимыми. С
> первым неестественным желанием появится и поддержка.

Такова жизнь.

> Это новое условие не ложится в текущую схему работы incominger. Мне
> садиться за перепланирование incominger для добавления этой суперфичи ?

Не знаю, что лучше, дорабатывать incominger или полностью всё переделать
под нормальный репозиторий исходников.


-- 
ldv

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

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Можно попробовать соптимизировать, применяя --query-repackage только
> тогда, когда иначе пакет не собирается из-за неудовлетворённых сборочных
> зависимостей.

Сборочные зависимости нужны до сборки всех пакетов чтобы построить
очередь и определить кого можно собирать параллельно. Иначе придётся
вернуться к последовательной сборке по buildtime.

> Не знаю, что лучше, дорабатывать incominger или полностью всё переделать
> под нормальный репозиторий исходников.

Поэтому я и задал вопрос :)
Особенно после некоторых наших обсуждений.

-- 
Rgrds, legion

Re: [devel] Проблема с incominger

[Anton D. Kachalov]

On Mon, Nov 14, 2005 at 03:56:12AM +0300, Dmitry V. Levin wrote:
> Не знаю, что лучше, дорабатывать incominger или полностью всё переделать
> под нормальный репозиторий исходников.
Думаю, знаешь :)
Лучше, разумеется, сделать нормальный репозитарий исходников. Так и архивы
держать проще будет, и собирать src.rpm. Можно что-то наподобии
kernel-cvs реализовать, но только не на cvs, а хотя бы на том же svn.

А доработка incominger - это костыли. И как известно, нет ничего более
постоянного, чем временное. Текущую брешь мы кое-как заткнём.
Но это не решение проблемы.

--
mouse

Re: [devel] Проблема с incominger

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Это в общем случае.  В реальности достаточно использовать
> --query-repackage.

Так как --query-repackage не работает во всех случаях.

cat >chroot/.host/query_req <<__EOF__
#!/bin/sh -e
rpmi -i -- "\$@"
cd \`rpm --eval %_specdir\`
rpmbuild -bs --nodeps $rpmargs -- *.spec >/dev/null
cd \`rpm --eval %_srcrpmdir\`
rpmquery -pR -- "\$@"
__EOF__

То при добавлении этой поддержки в incominger появляется новое
неестественное ограничение: в BuildRequires, взятых в условные блоки,
нельзя использовать макросы из пакетов, не устанавливаемых по ключу
--initroot-only.

Так например:
%ifnarch x86_64
BuildRequires: apache-devel >= %apache_version-%apache_release
BuildRequires: php-devel = %get_SVR php-devel
%endif

не обработаются. Такие конструкции допустимы, но --query-repackage с
ними не справится.

> Дело в том, что далеко не каждый имеет возможность собирать пакеты прямо
> в Сизиф минуя incominger с его неестественными ограничениями.

-- 
Rgrds, legion

[devel] Re: Проблема с hasher

[Michael Shigorin]

On Mon, Nov 14, 2005 at 01:09:41AM +0300, Alexey Gladkov wrote:
> > Обернуть соотв. BuildRequires %ifdef'ами?
> Этого делать нельзя. У такого пакета могут быть проблемы с incoming/.

Писал и думал -- что ж тут не так.  Спасибо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/