[devel] RPM и архитектура бинарных пакетов

[devel] RPM и архитектура бинарных пакетов

[Denis Ovsienko]

Господа!
Вчера мне ab указал на следующий недостаток: из
kernel-source-pentanet.src.rpm получается pentanet-tools.i586.rpm и
kernel-source-pentanet.i586.rpm, хотя последний --- единственный в своём
окружении, который не noarch. Когда подобный вопрос обсуждался в августе,
мне сказали, что rpm не мог из одного спека собирать пакеты для разных
архитектур. Теперь может?

--
    DO4-UANIC

Re: [devel] RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Fri, Oct 17, 2003 at 10:03:02AM +0300, Denis Ovsienko wrote:
> 
> Господа!
> Вчера мне ab указал на следующий недостаток: из
> kernel-source-pentanet.src.rpm получается pentanet-tools.i586.rpm и
> kernel-source-pentanet.i586.rpm, хотя последний --- единственный в своём
> окружении, который не noarch. Когда подобный вопрос обсуждался в августе,
> мне сказали, что rpm не мог из одного спека собирать пакеты для разных
> архитектур. Теперь может?
Нет, не может. Ладно, оставим это пока как есть, слишком много
переписывать надо будет в rpm...
-- 
/ Alexander Bokovoy
---
Only that in you which is me can hear what I'm saying.
		-- Baba Ram Dass

Re: [devel] RPM и архитектура бинарных пакетов

[Victor Forsyuk]

On Fri, Oct 17, 2003 at 10:03:02AM +0300, Denis Ovsienko wrote:
> 
> Господа!
> Вчера мне ab указал на следующий недостаток: из
> kernel-source-pentanet.src.rpm получается pentanet-tools.i586.rpm и
> kernel-source-pentanet.i586.rpm, хотя последний --- единственный в своём
> окружении, который не noarch. Когда подобный вопрос обсуждался в августе,
> мне сказали, что rpm не мог из одного спека собирать пакеты для разных
> архитектур. Теперь может?

Когда-то такой патч был в KSI Linux, сделан Витей Хименко.
RedHat'овцы успешно отбились от него, наговорив такого, что
я при всем желаниии аргументами назвать не могу. See here:

http://www.geocrawler.com/mail/thread.php3?subject=How+to+make+some+sub-packages+noarch+and+others+i386%3F&list=87

Re: [devel] RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Mon, Oct 20, 2003 at 04:35:50PM +0300, Victor Forsyuk wrote:
> On Fri, Oct 17, 2003 at 10:03:02AM +0300, Denis Ovsienko wrote:
> > 
> > Господа!
> > Вчера мне ab указал на следующий недостаток: из
> > kernel-source-pentanet.src.rpm получается pentanet-tools.i586.rpm и
> > kernel-source-pentanet.i586.rpm, хотя последний --- единственный в своём
> > окружении, который не noarch. Когда подобный вопрос обсуждался в августе,
> > мне сказали, что rpm не мог из одного спека собирать пакеты для разных
> > архитектур. Теперь может?
> 
> Когда-то такой патч был в KSI Linux, сделан Витей Хименко.
> RedHat'овцы успешно отбились от него, наговорив такого, что
> я при всем желаниии аргументами назвать не могу. See here:
> 
> http://www.geocrawler.com/mail/thread.php3?subject=How+to+make+some+sub-packages+noarch+and+others+i386%3F&list=87
Его аргументы вполне осмыслены с практической точки зрения
производственного процесса в компании RedHat. Позволю себе
переформулировать их:

1. Сборочная система в RH неспособна автоматически удалять 
неуникальные noarch.rpm, получаемые в результате сборки пакетов на
сборочных серверах с разной архитектурой и обрабатывать ситуации race
condition, возникающие из-за того, что  результаты сборки со всех серверов
попадают в один каталог на сервере-хранилище.

2. Исправление сборочной среды требует больше ресурсов, чем реально
выделено RedHat на поддержку сборочной среды и развитие RPM.

В таком контексте это вполне осмысленные аргументы.

Что касается нас, то:

1. В APT присутствует принципиальная возможность выделения noarch.rpm в
отдельный (под)репозитарий.

2. Написанный Виктором код уже есть и его можно использовать как затравку
для создания кода, который позволит, например, с дополнительным ключем не
упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
это позволит легко решить проблему RH(1).

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] RPM и архитектура бинарных пакетов

[Victor Forsyuk]

On Mon, Oct 20, 2003 at 04:51:24PM +0300, Alexander Bokovoy wrote:
> > 
> > Когда-то такой патч был в KSI Linux, сделан Витей Хименко.
> > RedHat'овцы успешно отбились от него, наговорив такого, что
> > я при всем желаниии аргументами назвать не могу. See here:
> > 
> > http://www.geocrawler.com/mail/thread.php3?subject=How+to+make+some+sub-packages+noarch+and+others+i386%3F&list=87
> Его аргументы вполне осмыслены с практической точки зрения
> производственного процесса в компании RedHat. Позволю себе
> переформулировать их:
> 
> 1. Сборочная система в RH неспособна автоматически удалять 
> неуникальные noarch.rpm, получаемые в результате сборки пакетов на
> сборочных серверах с разной архитектурой и обрабатывать ситуации race
> condition, возникающие из-за того, что  результаты сборки со всех серверов
> попадают в один каталог на сервере-хранилище.
> 
> 2. Исправление сборочной среды требует больше ресурсов, чем реально
> выделено RedHat на поддержку сборочной среды и развитие RPM.
> 
> В таком контексте это вполне осмысленные аргументы.

Саша, я не говорил, что их аргументы _бессмысленны_ :). Это было бы просто
неуважением к Jeff Johnson. :) Другое дело, что его ответ был классической
_отмазкой_. Редхетовцам это было ненужно и они этот патч тихо-мирно
выбросили. 

"Why all features of RPM should be used in Red Hat's build process?" - этот
Витин вопрос остался без ответа. Никто ведь не принуждает РедХет
пользоваться фичей, поддержку которой их попросили включить в rpm.

> Что касается нас, то:
> 
> 1. В APT присутствует принципиальная возможность выделения noarch.rpm в
> отдельный (под)репозитарий.
> 
> 2. Написанный Виктором код уже есть и его можно использовать как затравку
> для создания кода, который позволит, например, с дополнительным ключем не
> упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
> это позволит легко решить проблему RH(1).

Согласен, но есть ли у ldv@ желание этот код создавать?

p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
в buildroot пропущенных в %files файлов... ;-)
Я был бы тогда в два раза счастливее - как кот Матроскин :)

Re: [devel] RPM и архитектура бинарных пакетов

[Dmitry V. Levin]

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

On Tue, Oct 21, 2003 at 07:27:07PM +0300, Victor Forsyuk wrote:
> On Mon, Oct 20, 2003 at 04:51:24PM +0300, Alexander Bokovoy wrote:
> > > 
> > > Когда-то такой патч был в KSI Linux, сделан Витей Хименко.
> > > RedHat'овцы успешно отбились от него, наговорив такого, что
> > > я при всем желаниии аргументами назвать не могу. See here:
> > > 
> > > http://www.geocrawler.com/mail/thread.php3?subject=How+to+make+some+sub-packages+noarch+and+others+i386%3F&list=87
> > Его аргументы вполне осмыслены с практической точки зрения
> > производственного процесса в компании RedHat. Позволю себе
> > переформулировать их:
> > 
> > 1. Сборочная система в RH неспособна автоматически удалять 
> > неуникальные noarch.rpm, получаемые в результате сборки пакетов на
> > сборочных серверах с разной архитектурой и обрабатывать ситуации race
> > condition, возникающие из-за того, что  результаты сборки со всех серверов
> > попадают в один каталог на сервере-хранилище.
> > 
> > 2. Исправление сборочной среды требует больше ресурсов, чем реально
> > выделено RedHat на поддержку сборочной среды и развитие RPM.
> > 
> > В таком контексте это вполне осмысленные аргументы.
> 
> Саша, я не говорил, что их аргументы _бессмысленны_ :). Это было бы просто
> неуважением к Jeff Johnson. :) Другое дело, что его ответ был классической
> _отмазкой_. Редхетовцам это было ненужно и они этот патч тихо-мирно
> выбросили. 
> 
> "Why all features of RPM should be used in Red Hat's build process?" - этот
> Витин вопрос остался без ответа. Никто ведь не принуждает РедХет
> пользоваться фичей, поддержку которой их попросили включить в rpm.

На самом деле один аргумент всё-таки был приведён:
Эта возможность создаёт риск создания большего количества
труднообнаруживаемых не_совсем_noarch-пакетов, чем оно есть сейчас.

Впрочем, всякой возможностью можно злоупотребить.

> > Что касается нас, то:
> > 
> > 1. В APT присутствует принципиальная возможность выделения noarch.rpm в
> > отдельный (под)репозитарий.
> > 
> > 2. Написанный Виктором код уже есть и его можно использовать как затравку
> > для создания кода, который позволит, например, с дополнительным ключем не
> > упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
> > это позволит легко решить проблему RH(1).

Как говорит Andrew Morgan, "Show me the code".

> Согласен, но есть ли у ldv@ желание этот код создавать?

Этот вопрос имеет смысл ставить только при наличии >1 полноценно
поддерживаемой архитектуры в Сизифе.

Что не значит, что никто не может сделать это раньше. :)

> p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
> в buildroot пропущенных в %files файлов... ;-)
> Я был бы тогда в два раза счастливее - как кот Матроскин :)

Это вопрос времени.
У меня, в принципе, есть патч к rpm-4_0_branch.


-- 
ldv

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

Re: [devel] RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Tue, Oct 21, 2003 at 09:39:49PM +0400, Dmitry V. Levin wrote:
> > > 2. Исправление сборочной среды требует больше ресурсов, чем реально
> > > выделено RedHat на поддержку сборочной среды и развитие RPM.
> > > 
> > > В таком контексте это вполне осмысленные аргументы.
> > 
> > Саша, я не говорил, что их аргументы _бессмысленны_ :). Это было бы просто
> > неуважением к Jeff Johnson. :) Другое дело, что его ответ был классической
> > _отмазкой_. Редхетовцам это было ненужно и они этот патч тихо-мирно
> > выбросили. 
> > 
> > "Why all features of RPM should be used in Red Hat's build process?" - этот
> > Витин вопрос остался без ответа. Никто ведь не принуждает РедХет
> > пользоваться фичей, поддержку которой их попросили включить в rpm.
> 
> На самом деле один аргумент всё-таки был приведён:
> Эта возможность создаёт риск создания большего количества
> труднообнаруживаемых не_совсем_noarch-пакетов, чем оно есть сейчас.
> 
> Впрочем, всякой возможностью можно злоупотребить.
Отвечу тут сразу и тебе, и Виктору. Мы обсуждали использование подобного
механизма с Сергеем Большаковым, поскольку имеем уже необходимость в связи
с постепенной пересборкой серверной части Сизифа под XScale. Результатом
было вот такое предварительное распределение:

- в патч добавляется возможность сборки с игнорированием упаковки
  подпакетов с указанными TargetArch, скажем, --disable targetarch
  
- сборочные сервера для специфических архитектур собирают свои пакеты

- одна архитектура объявляется основной для генерации noarch.rpm,
  сборочные сервера остальных совместимых по, скажем, endiannes, архитектур 
  получают в своих настройках указание запрещать TargetArch

- Результирующие пакеты укладываются в два репозитария -- noarch и Arch
  (i586, v5l, ...), в системе в конфигурации apt прописываются оба
  репозитария

Это позволит использовать достаточно гибко предлагаемый функционал.

> > > Что касается нас, то:
> > > 
> > > 1. В APT присутствует принципиальная возможность выделения noarch.rpm в
> > > отдельный (под)репозитарий.
> > > 
> > > 2. Написанный Виктором код уже есть и его можно использовать как затравку
> > > для создания кода, который позволит, например, с дополнительным ключем не
> > > упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
> > > это позволит легко решить проблему RH(1).
> 
> Как говорит Andrew Morgan, "Show me the code".
Да. К сожалению, архивы рассылки в crawler-е не хранят патчи.

 
> > Согласен, но есть ли у ldv@ желание этот код создавать?
> 
> Этот вопрос имеет смысл ставить только при наличии >1 полноценно
> поддерживаемой архитектуры в Сизифе.
> 
> Что не значит, что никто не может сделать это раньше. :)
Фактически, у нас уже есть i586 и v5l. Последняя, видимо, станет публичной
еще до нового года при хорошем стечении обстоятельств.
 
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] RPM и архитектура бинарных пакетов

[Dmitry V. Levin]

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

On Tue, Oct 21, 2003 at 11:45:36PM +0300, Alexander Bokovoy wrote:
[...]
> Отвечу тут сразу и тебе, и Виктору. Мы обсуждали использование подобного
> механизма с Сергеем Большаковым, поскольку имеем уже необходимость в связи
> с постепенной пересборкой серверной части Сизифа под XScale. Результатом
> было вот такое предварительное распределение:
> 
> - в патч добавляется возможность сборки с игнорированием упаковки
>   подпакетов с указанными TargetArch, скажем, --disable targetarch

Я бы предпочёл параметр --target-only (как бы в дополнение к --target=arch),
который бы исключал упаковку всего, что не является arch.

Можно провести через rpmpopt как alias на define, так даже проще, можно
будет в .rpmmacros указать.  Впрочем, это уже детали.

> - сборочные сервера для специфических архитектур собирают свои пакеты
> 
> - одна архитектура объявляется основной для генерации noarch.rpm,
>   сборочные сервера остальных совместимых по, скажем, endiannes, архитектур 
>   получают в своих настройках указание запрещать TargetArch
> 
> - Результирующие пакеты укладываются в два репозитария -- noarch и Arch
>   (i586, v5l, ...), в системе в конфигурации apt прописываются оба
>   репозитария
> 
> Это позволит использовать достаточно гибко предлагаемый функционал.

Логично.


-- 
ldv

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

Re: [devel] RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Wed, Oct 22, 2003 at 01:03:07AM +0400, Dmitry V. Levin wrote:
> On Tue, Oct 21, 2003 at 11:45:36PM +0300, Alexander Bokovoy wrote:
> [...]
> > Отвечу тут сразу и тебе, и Виктору. Мы обсуждали использование подобного
> > механизма с Сергеем Большаковым, поскольку имеем уже необходимость в связи
> > с постепенной пересборкой серверной части Сизифа под XScale. Результатом
> > было вот такое предварительное распределение:
> > 
> > - в патч добавляется возможность сборки с игнорированием упаковки
> >   подпакетов с указанными TargetArch, скажем, --disable targetarch
> 
> Я бы предпочёл параметр --target-only (как бы в дополнение к --target=arch),
> который бы исключал упаковку всего, что не является arch.
> 
> Можно провести через rpmpopt как alias на define, так даже проще, можно
> будет в .rpmmacros указать.  Впрочем, это уже детали.
Именно, это детали. Важнее эту функциональность втянуть.


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] RPM и архитектура бинарных пакетов

[Canis Cerberus]

> - Результирующие пакеты укладываются в два репозитария -- noarch и Arch
>   (i586, v5l, ...), в системе в конфигурации apt прописываются оба

> Фактически, у нас уже есть i586 и v5l. Последняя, видимо, станет публичной
> еще до нового года при хорошем стечении обстоятельств.
А что за архитектура "v5l"? если не секрет
-- 
Canis Cerberus
Magna est veritas et praevalebit !
Санкт-Петербург

Re: [devel] RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Wed, Oct 22, 2003 at 09:50:40PM +0400, Canis Cerberus wrote:
> > - Результирующие пакеты укладываются в два репозитария -- noarch и Arch
> >   (i586, v5l, ...), в системе в конфигурации apt прописываются оба
> 
> > Фактически, у нас уже есть i586 и v5l. Последняя, видимо, станет публичной
> > еще до нового года при хорошем стечении обстоятельств.
> А что за архитектура "v5l"? если не секрет
Я же уже сказал выше -- XScale.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re[2]: [devel] RPM É ÁÒÈÉÔÅËÔÕÒÁ ÂÉÎÁÒÎÙÈ ÐÁËÅÔÏ×

[Volkov Serge]

Hello Dmitry,

Tuesday, October 21, 2003, 9:39:49 PM, you wrote:

DVL> On Tue, Oct 21, 2003 at 07:27:07PM +0300, Victor Forsyuk wrote:
>> On Mon, Oct 20, 2003 at 04:51:24PM +0300, Alexander Bokovoy wrote:
>> > > 
>> > > Когда-то такой патч был в KSI Linux, сделан Витей Хименко.
>> > > RedHat'овцы успешно отбились от него, наговорив такого, что
>> > > я при всем желаниии аргументами назвать не могу. See here:
>> > > 
>> > > http://www.geocrawler.com/mail/thread.php3?subject=How+to+make+some+sub-packages+noarch+and+others+i386%3F&list=87
>> > Его аргументы вполне осмыслены с практической точки зрения
>> > производственного процесса в компании RedHat. Позволю себе
>> > переформулировать их:
>> > 
>> > 1. Сборочная система в RH неспособна автоматически удалять 
>> > неуникальные noarch.rpm, получаемые в результате сборки пакетов на
>> > сборочных серверах с разной архитектурой и обрабатывать ситуации race
>> > condition, возникающие из-за того, что  результаты сборки со всех серверов
>> > попадают в один каталог на сервере-хранилище.
>> > 
>> > 2. Исправление сборочной среды требует больше ресурсов, чем реально
>> > выделено RedHat на поддержку сборочной среды и развитие RPM.
>> > 
>> > В таком контексте это вполне осмысленные аргументы.
>> 
>> Саша, я не говорил, что их аргументы _бессмысленны_ :). Это было бы просто
>> неуважением к Jeff Johnson. :) Другое дело, что его ответ был классической
>> _отмазкой_. Редхетовцам это было ненужно и они этот патч тихо-мирно
>> выбросили. 
>> 
>> "Why all features of RPM should be used in Red Hat's build process?" - этот
>> Витин вопрос остался без ответа. Никто ведь не принуждает РедХет
>> пользоваться фичей, поддержку которой их попросили включить в rpm.

DVL> На самом деле один аргумент всё-таки был приведён:
DVL> Эта возможность создаёт риск создания большего количества
DVL> труднообнаруживаемых не_совсем_noarch-пакетов, чем оно есть сейчас.

DVL> Впрочем, всякой возможностью можно злоупотребить.

>> > Что касается нас, то:
>> > 
>> > 1. В APT присутствует принципиальная возможность выделения noarch.rpm в
>> > отдельный (под)репозитарий.
>> > 
>> > 2. Написанный Виктором код уже есть и его можно использовать как затравку
>> > для создания кода, который позволит, например, с дополнительным ключем не
>> > упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
>> > это позволит легко решить проблему RH(1).

DVL> Как говорит Andrew Morgan, "Show me the code".

>> Согласен, но есть ли у ldv@ желание этот код создавать?

DVL> Этот вопрос имеет смысл ставить только при наличии >1 полноценно
DVL> поддерживаемой архитектуры в Сизифе.

А почему бы и нет если удасться уговорить IBM сертифицировать ALT как
поддерживаемый дистрибутив :))

DVL> Что не значит, что никто не может сделать это раньше. :)

>> p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
>> в buildroot пропущенных в %files файлов... ;-)
>> Я был бы тогда в два раза счастливее - как кот Матроскин :)

DVL> Это вопрос времени.
DVL> У меня, в принципе, есть патч к rpm-4_0_branch.





-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] RPM и архитектура бинарных пакетов

[Victor Forsyuk]

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

On Tue, Oct 21, 2003 at 09:39:49PM +0400, Dmitry V. Levin wrote:

> > "Why all features of RPM should be used in Red Hat's build process?" - этот
> > Витин вопрос остался без ответа. Никто ведь не принуждает РедХет
> > пользоваться фичей, поддержку которой их попросили включить в rpm.
> 
> На самом деле один аргумент всё-таки был приведён:
> Эта возможность создаёт риск создания большего количества
> труднообнаруживаемых не_совсем_noarch-пакетов, чем оно есть сейчас.
> 
> Впрочем, всякой возможностью можно злоупотребить.

Именно! Наличие ножа в доме создает риск порезаться (если им пользоваться
неосторожно). Но не не совсем понятен аргумент убрать все ножи из дома:
боишься ножа - не пользуйся им :)
 
> > > 2. Написанный Виктором код уже есть и его можно использовать как затравку
> > > для создания кода, который позволит, например, с дополнительным ключем не
> > > упаковывать подпакеты с выбранной архитектурой, отличной от собираемой -- 
> > > это позволит легко решить проблему RH(1).
> 
> Как говорит Andrew Morgan, "Show me the code".

See attach.
 
> > p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
> > в buildroot пропущенных в %files файлов... ;-)
> > Я был бы тогда в два раза счастливее - как кот Матроскин :)
> 
> Это вопрос времени.

[мечтательно] Вот бы быстрее это время наступило. :)

> У меня, в принципе, есть патч к rpm-4_0_branch.



[-- Attachment #2: ksi-rpm-3.0.4-targetarch.patch --]
[-- Type: text/plain, Size: 6025 bytes --]

diff -urN rpm-4.0.3.orig/build/pack.c rpm-4.0.3/build/pack.c
--- rpm-4.0.3.orig/build/pack.c	Tue Apr 17 22:26:32 2001
+++ rpm-4.0.3/build/pack.c	Sun Jun 17 18:14:31 2001
@@ -443,8 +443,20 @@
 
 	if (Fileno(csa->cpioFdIn) < 0) {
 #ifndef	DYING
+	  if (headerIsEntry(h, RPMTAG_ARCH)) {
+	    char *_arch;
+	    headerGetEntry(h, RPMTAG_ARCH, NULL, (void **)&_arch, NULL);
+	    rpmGetArchNum(_arch, &archnum);
+	  } else {
 	    rpmGetArchInfo(NULL, &archnum);
+	  }
+	  if (headerIsEntry(h, RPMTAG_OS)) {
+	    char *_os;
+	    headerGetEntry(h, RPMTAG_OS, NULL, (void **)&_os, NULL);
+	    rpmGetOsNum(_os, &osnum);
+	  } else {
 	    rpmGetOsInfo(NULL, &osnum);
+	  }
 #endif
 	} else if (csa->lead != NULL) {
 	    archnum = csa->lead->archnum;
diff -urN rpm-3.0.4.orig/build/parsePreamble.c rpm-3.0.4/build/parsePreamble.c
--- rpm-3.0.4.orig/build/parsePreamble.c	Tue Aug 24 17:09:22 1999
+++ rpm-3.0.4/build/parsePreamble.c	Thu Sep 30 20:11:20 1999
@@ -140,6 +140,7 @@
 {
     const char *arch = NULL;
     const char *os = NULL;
+    Package pkg;
 
     rpmGetArchInfo(&arch, NULL);
     rpmGetOsInfo(&os, NULL);
@@ -154,6 +155,23 @@
 	rpmError(RPMERR_BADSPEC, _("Architecture is not included: %s"), arch);
 	return RPMERR_BADSPEC;
     }
+    pkg = spec->packages;
+    while (pkg) {
+       if (headerIsEntry(pkg->header, RPMTAG_ARCH)) {
+           headerGetEntry(pkg->header, RPMTAG_ARCH, NULL, (void **)&arch, NULL);
+           if (isMemberInEntry(spec->buildRestrictions,
+                               arch, RPMTAG_EXCLUDEARCH) == 1) {
+               rpmError(RPMERR_BADSPEC, _("Architecture is excluded: %s"), arch);
+               return RPMERR_BADSPEC;
+           }
+           if (isMemberInEntry(spec->buildRestrictions,
+                       arch, RPMTAG_EXCLUSIVEARCH) == 0) {
+               rpmError(RPMERR_BADSPEC, _("Architecture is not included: %s"), arch);
+               return RPMERR_BADSPEC;
+           }
+       }
+       pkg = pkg->next;
+    }
     if (isMemberInEntry(spec->buildRestrictions,
 			os, RPMTAG_EXCLUDEOS) == 1) {
 	rpmError(RPMERR_BADSPEC, _("OS is excluded: %s"), os);
@@ -164,6 +182,23 @@
 	rpmError(RPMERR_BADSPEC, _("OS is not included: %s"), os);
 	return RPMERR_BADSPEC;
     }
+    pkg = spec->packages;
+    while (pkg) {
+       if (headerIsEntry(pkg->header, RPMTAG_OS)) {
+           headerGetEntry(pkg->header, RPMTAG_OS, NULL, (void **)&os, NULL);
+           if (isMemberInEntry(spec->buildRestrictions,
+                               os, RPMTAG_EXCLUDEOS) == 1) {
+               rpmError(RPMERR_BADSPEC, _("OS is excluded: %s"), os);
+               return RPMERR_BADSPEC;
+           }
+           if (isMemberInEntry(spec->buildRestrictions,
+                               os, RPMTAG_EXCLUSIVEOS) == 0) {
+               rpmError(RPMERR_BADSPEC, _("OS is not included: %s"), os);
+               return RPMERR_BADSPEC;
+           }
+       }
+       pkg = pkg->next;
+    }
 
     return 0;
 }
@@ -367,6 +402,8 @@
       case RPMTAG_NAME:
       case RPMTAG_VERSION:
       case RPMTAG_RELEASE:
+      case RPMTAG_ARCH:
+      case RPMTAG_OS:
       case RPMTAG_URL:
 	SINGLE_TOKEN_ONLY;
 	/* These macros are for backward compatibility */
@@ -611,7 +648,9 @@
     {RPMTAG_AUTOREQPROV,	0, 0, "autoreqprov"},
     {RPMTAG_AUTOREQ,		0, 0, "autoreq"},
     {RPMTAG_AUTOPROV,		0, 0, "autoprov"},
-    {RPMTAG_DOCDIR,		0, 0, "docdir"},
+    {RPMTAG_DOCDIR,		0, 0, "docdir"},
+    {RPMTAG_ARCH,		0, 0, "targetarch"},
+    {RPMTAG_OS,			0, 0, "targetos"},
     {0, 0, 0, 0}
 };
 
diff -urN rpm-3.0.3.orig/build/parseSpec.c rpm-3.0.3/build/parseSpec.c
--- rpm-3.0.3.orig/build/parseSpec.c	Mon Sep  6 23:51:54 1999
+++ rpm-3.0.3/build/parseSpec.c	Thu Sep 30 20:11:20 1999
@@ -496,8 +496,10 @@
 	    return RPMERR_BADSPEC;
 	}
 
-	headerAddEntry(pkg->header, RPMTAG_OS, RPM_STRING_TYPE, os, 1);
-	headerAddEntry(pkg->header, RPMTAG_ARCH, RPM_STRING_TYPE, arch, 1);
+       if (!headerIsEntry(pkg->header, RPMTAG_OS))
+           headerAddEntry(pkg->header, RPMTAG_OS, RPM_STRING_TYPE, os, 1);
+       if (!headerIsEntry(pkg->header, RPMTAG_ARCH))
+           headerAddEntry(pkg->header, RPMTAG_ARCH, RPM_STRING_TYPE, arch, 1);
       }
       FREE(myos);
     }
diff -urN rpm-4.0.3.orig/lib/rpmlib.h rpm-4.0.3/lib/rpmlib.h
--- rpm-4.0.3.orig/lib/rpmlib.h	Thu Apr 19 18:11:00 2001
+++ rpm-4.0.3/lib/rpmlib.h	Sun Jun 17 18:08:16 2001
@@ -475,6 +475,7 @@
  * @retval num		address of arch number (or NULL)
  */
 void rpmGetArchInfo( /*@out@*/ const char ** name, /*@out@*/ int * num);
+void rpmGetArchNum(char * name, int * num);
 
 /** \ingroup rpmrc
  * Return current os name and/or number.
@@ -483,6 +484,7 @@
  * @retval num		address of os number (or NULL)
  */
 void rpmGetOsInfo( /*@out@*/ const char ** name, /*@out@*/ int * num);
+void rpmGetOsNum(char * name, int * num);
 
 /** \ingroup rpmrc
  * Return arch/os score of a name.
diff -urN rpm-3.0.3.orig/lib/rpmrc.c rpm-3.0.3/lib/rpmrc.c
--- rpm-3.0.3.orig/lib/rpmrc.c	Mon Aug 16 19:05:03 1999
+++ rpm-3.0.3/lib/rpmrc.c	Thu Sep 30 20:11:20 1999
@@ -1136,6 +1136,38 @@
     getMachineInfo(OS, name, num);
 }
 
+static void getNum(int type, char * name, int * num) {
+    struct canonEntry * canon;
+    int which = currTables[type];
+
+    /* use the normal canon tables, even if we're looking up build stuff */
+    if (which >= 2) which -= 2;
+
+    canon = lookupInCanonTable(name, 
+			       tables[which].canons,
+			       tables[which].canonsLength);
+
+    if (canon) {
+	if (num) *num = canon->num;
+    } else {
+	if (num) *num = 255;
+
+	if (tables[currTables[type]].hasCanon) {
+	    rpmMessage(RPMMESS_WARNING, _("Unknown system: %s\n"), name);
+/*	    rpmMessage(RPMMESS_WARNING, _("Please contact rpm-list@redhat.com\n"));*/
+	}
+    }
+}
+
+void rpmGetArchNum(char * name, int * num) {
+    getNum(ARCH, name, num);
+}
+
+void rpmGetOsNum(char * name, int * num) {
+    getNum(OS, name, num);
+}
+
+
 void rpmRebuildTargetVars(const char **buildtarget, const char ** canontarget)
 {
 

Re: [devel] RPM %_unpackaged_files_terminate_build

[Dmitry V. Levin]

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

On Fri, Oct 24, 2003 at 09:25:40PM +0300, Victor Forsyuk wrote:
> On Tue, Oct 21, 2003 at 09:39:49PM +0400, Dmitry V. Levin wrote:
[...]
> > > p.s. [вполголоса] А вот если бы ещё возможность прерывать сборку при наличии
> > > в buildroot пропущенных в %files файлов... ;-)
> > > Я был бы тогда в два раза счастливее - как кот Матроскин :)
> > 
> > Это вопрос времени.
> 
> [мечтательно] Вот бы быстрее это время наступило. :)
> 
> > У меня, в принципе, есть патч к rpm-4_0_branch.

$ rpmquery --lastchange rpm |sed -e 's/@[^>]*>/@>/g' |grep -v '^$'
* Sun Nov 09 2003 Dmitry V. Levin <ldv@> 4.0.4-alt27
- helper shell scripts:
  + use printf instead of echo where appropriate;
  + moved common code to /usr/lib/rpm/functions.
- Implemented %_unpackaged_files_terminate_build support.
- rpm-build: do not package /usr/lib/rpm/mkinstalldirs.
- Do not package build-topdir subpackage by default.
- verify_elf: implemented TEXTREL checking.
- Updated README.ALT-ru_RU.KOI8-R.


-- 
ldv

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

[devel] Re: RPM и архитектура бинарных пакетов

[Alexey Tourbin]

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

On Tue, Oct 21, 2003 at 07:27:07PM +0300, Victor Forsyuk wrote:
> p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
> в buildroot пропущенных в %files файлов... ;-)

Мне не очень нравится эта идея.  Например, devel-static пакеты без
необходимости обычно не пакуются, а в %buildroot'е эти статические
библиотеки иногда лежат.

> Я был бы тогда в два раза счастливее - как кот Матроскин :)

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

Re: [devel] Re: RPM и архитектура бинарных пакетов

[Alexander Bokovoy]

On Wed, Oct 22, 2003 at 06:52:18PM +0400, Alexey Tourbin wrote:
> On Tue, Oct 21, 2003 at 07:27:07PM +0300, Victor Forsyuk wrote:
> > p.s. [вполголоса] А вот если бы еще возможность прерывать сборку при наличии
> > в buildroot пропущенных в %files файлов... ;-)
> 
> Мне не очень нравится эта идея.  Например, devel-static пакеты без
> необходимости обычно не пакуются, а в %buildroot'е эти статические
> библиотеки иногда лежат.
В этом случае, если упаковщик принципиально не хочет упаковывать
статические библиотеки, более осмысленным будет указать их непосредственно
в спек-файле в списке исключений с тем, чтобы при поиске пропущенных в
%files файлов их игнорировали, но ругались, если они на самом деле в
%%buildroot отсутствуют -- это может быть хорошим знаком того, что
%статическая сборка сломалась.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/