[devel] [RFP]: %altrelease macro

[devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Задумал я облегчить сборку пакетов в среде установленного дистрибутива и
для репозитариев updates/backports. У нас есть некоторые требования по
отношению к наименованию релизов (тэг Release) в таких пакетах, вкратце
формулируемые так:

Тэг Release для пакета, собираемого в updates/backports, должен
содержать запись специального вида, облегчающую последующее обновление
пакета из более нового дистрибутива (или Sisyphus).

Это означает, что спек-файл пакета на самом деле претерпевает
определенные изменения (по меньшей мере, тэг Release) и фактически
вынуждает поддерживать две версии пакета даже в том случае, когда
никаких других изменений в пакет не вносится.

Однако можно изменить ситуацию так, чтобы не требовалось модифицировать
тэг Release (а просто пересобирать пакет). Для этого необходимо
предоставлять дополнительную информацию о сборочной среде в ней самой,
чтобы не передавать ее через специальные опции сборочной системы.
Последнее -- важное требование, оно связано с тем, что при использовании
  hasher мы в общем случае не влияем на сборку, особенно при сборке
"роботами".

Мое предложение состоит в том, чтобы в практически единственный пакет,
который у нас гарантированно изменяется при выпуске новой версии
дистрибутива -- altlinux-release добавить несколько дополнительных
файлов, которые и обеспечат решение поставленной задачи. При одном
дополнительном "но", о котором чуть позже.

Представим, что в altlinux-release у нас присутствуют следующие файлы:
$ LANG=C rpm -ql altlinux-release
/etc/altlinux-release
/etc/buildreqs/packages/ignore.d/altlinux-release
/etc/mandrake-release
/etc/redhat-release
/etc/rpm/macros.d/00altlinux-release-macros
/etc/rpm/rpm-grt.conf
/etc/sisyphus-release
/usr/lib/rpm/rpm-generate-release-tag

Три из них -- новые, это /etc/rpm/macros.d/00altlinux-release-macros,
/etc/rpm/rpm-grt.conf и /usr/lib/rpm/rpm-generate-release-tag. Первый --
однострочный макрос для RPM, второй -- файл конфигурации для третьего,
который собственно и генерирует необходимый нам вид тэга Release.

Файл конфигурации rpm-grt.conf содержит всего две значимые строчки:
# Define distribution shortcut name and prefix for release tags
# An empty value of DISTRO_SHORTCUT corresponds to Sysiphus
DISTRO_SHORTCUT=M40
DISTRO_PREFIX=alt

rpm-generate-release-tag использует их для того, чтобы сконструировать
значение тэга Release. Если DISTRO_SHORTCUT пуст (мы имеем дело с
Sisyphus), то результат работы rpm-generate-release-tag --
${DISTRO_PREFIX}${release}, где ${release} -- первый параметр, поданный
на вход программы.

Если DISTRO_SHORTCUT содержит некоторое значение, (M40 в нашем случае),
то мы имеем дело с уже выпущенным дистрибутивом и это означает. что для
этого дистрибутива нам требуется модифицировать Release:
1. Уменьшить желаемое значение ${release} на единицу
2. после ${DISTRO_PREFIX}${release} дописать ${DISTRO_SHORTCUT} через точку
3. Далее (опционально) вписать локальный номер релиза для этой сборки
(второй аргумент команды rpm-generate-release-tag), а если он не указан,
то вписать 0.

В таком случае у нас получится тэг Release со значением, например,
alt2.M40.0 для пакета, который в Sisyphus имеет релиз alt3.

Все это возможно использовать в любом выпущенном дистрибутиве, записав в
  качестве аргумента тэга Release макрос %altrelease с нужным значением
(или двумя, если еще нужен локальный номер релиза, отличный от нуля),
достаточно только обновить во всех таких дистрибутивах пакет
altlinux-release.

Вот пример:
$ head -n6 librfid.spec
name:           librfid
version:        0.1.0
summary:        The librfid is a Free Software RFID library
Release:        %altrelease 2
Group:          System Environment/Libraries
License:        GPLv2

В системе на основе Server 4.0 результат будет следующим:
$ LANG=C rpmbuild -bE librfid.spec | head -n6
name:           librfid
version:        0.1.0
summary:        The librfid is a Free Software RFID library
Release:        alt1.M40.0
Group:          System Environment/Libraries
License:        GPLv2

В Сизифе будет обычный Release: alt2

Нужно ли такое?

Обновленный altlinux-release можно найти у меня в git.alt. Пример сборки
для Server 4.0:
rpmbuild -ba --define 'distro_scut M40' --define 'distro Server' \
	--define 'text_file ALT Linux 4.0 Server (Walnut)' \
	altlinux-release.spec

-- 
/ 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] [RFP]: %altrelease macro

[Sergey Bolshakov]

>>>>> "Alexander" == Alexander Bokovoy <ab@altlinux.org> writes:

 > Задумал я облегчить сборку пакетов в среде установленного дистрибутива и
 > для репозитариев updates/backports. У нас есть некоторые требования по
 > отношению к наименованию релизов (тэг Release) в таких пакетах, вкратце
 > формулируемые так:
[skipped]

К сожалению, генерат в значении тэга release плохо
совместим с gear в части раскрытия @release@ в .gear-rules
Для меня это stopper.

-- 

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Sergey Bolshakov пишет:
>>>>>> "Alexander" == Alexander Bokovoy <ab@altlinux.org> writes:
> 
>> Задумал я облегчить сборку пакетов в среде установленного
>> дистрибутива и для репозитариев updates/backports. У нас есть
>> некоторые требования по отношению к наименованию релизов (тэг
>> Release) в таких пакетах, вкратце формулируемые так:
> [skipped]
> 
> К сожалению, генерат в значении тэга release плохо совместим с gear в
> части раскрытия @release@ в .gear-rules Для меня это stopper.
Почему он не может раскрываться в этот макрос в .gear-rules?

-- 
/ 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] [RFP]: %altrelease macro

[Sergey Vlasov]

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

On Sun, Dec 16, 2007 at 09:40:22PM +0300, Alexander Bokovoy wrote:
> Sergey Bolshakov пишет:
> >>>>>> "Alexander" == Alexander Bokovoy <ab@altlinux.org> writes:
> > 
> >> Задумал я облегчить сборку пакетов в среде установленного
> >> дистрибутива и для репозитариев updates/backports. У нас есть
> >> некоторые требования по отношению к наименованию релизов (тэг
> >> Release) в таких пакетах, вкратце формулируемые так:
> > [skipped]
> > 
> > К сожалению, генерат в значении тэга release плохо совместим с gear в
> > части раскрытия @release@ в .gear-rules Для меня это stopper.
> Почему он не может раскрываться в этот макрос в .gear-rules?

Полноценное раскрытие макросов RPM подразумевает возможность
выполнения произвольного кода из spec-файла, а также может требовать
наличия в окружении некоторых установленных пакетов, поэтому gear не
может его использовать.  В последней версии gear есть поддержка
макросов простейшего вида (%define без параметров), реализованная
через скрипт на awk, но макросы с параметрами таким образом обработаны
не будут (при обнаружении неизвестного макроса или конструкции с '%'
неподдерживаемого вида скрипт просто возвращает значение в том виде,
как оно записано в spec).  Можно разве что добавить в этот скрипт
специальную обработку для каждого макроса с параметрами, который
необходимо раскрывать.

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

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Sergey Vlasov пишет:
>>> К сожалению, генерат в значении тэга release плохо совместим с
>>> gear в части раскрытия @release@ в .gear-rules Для меня это
>>> stopper.
>> Почему он не может раскрываться в этот макрос в .gear-rules?
> 
> Полноценное раскрытие макросов RPM подразумевает возможность 
> выполнения произвольного кода из spec-файла, а также может требовать 
> наличия в окружении некоторых установленных пакетов, поэтому gear не 
> может его использовать.  В последней версии gear есть поддержка 
> макросов простейшего вида (%define без параметров), реализованная 
> через скрипт на awk, но макросы с параметрами таким образом
> обработаны не будут (при обнаружении неизвестного макроса или
> конструкции с '%' неподдерживаемого вида скрипт просто возвращает
> значение в том виде, как оно записано в spec).  Можно разве что
> добавить в этот скрипт специальную обработку для каждого макроса с
> параметрами, который необходимо раскрывать.
Предлагаемое решение опирается на наличие скрипта
/usr/lib/rpm/rpm-generate-release-tag в altlinux-release (пакет, который
есть в любой системе ALT Linux, сформированной при помощи rpm, поскольку
он входит в список зависимостей пакета basesystem).

-- 
/ 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] [RFP]: %altrelease macro

[Sergey Vlasov]

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

On Sun, Dec 16, 2007 at 10:37:36PM +0300, Alexander Bokovoy wrote:
> Предлагаемое решение опирается на наличие скрипта
> /usr/lib/rpm/rpm-generate-release-tag в altlinux-release (пакет, который
> есть в любой системе ALT Linux, сформированной при помощи rpm, поскольку
> он входит в список зависимостей пакета basesystem).

Однако в altlinux-release есть не только скрипт, но и файл
конфигурации, от которого зависит результат работы скрипта.
Получается, что для получения правильного результата в любом случае
нужно создавать hasher chroot с нужной версией altlinux-release и
выполнять раскрытие макросов там; теоретически можно попытаться это
сделать, но это не вписывается в текущую логику работы gear (где
--hasher - это только один из возможных режимов работы).  Что делать,
например, с gear --describe?

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

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Sergey Vlasov пишет:
> Однако в altlinux-release есть не только скрипт, но и файл 
> конфигурации, от которого зависит результат работы скрипта. 
> Получается, что для получения правильного результата в любом случае 
> нужно создавать hasher chroot с нужной версией altlinux-release и 
> выполнять раскрытие макросов там; теоретически можно попытаться это 
> сделать, но это не вписывается в текущую логику работы gear (где 
> --hasher - это только один из возможных режимов работы).  Что делать,
>  например, с gear --describe?
Файл конфигурации описывает именно текущую систему, предполагается, что
он не будет изменяться пользователем, а будет приходить в систему с ее
установкой (обновлением). То есть, можно считать, что это одно из
свойств системы, в которой рассматривается пакет, поэтому специально 
никакой чрут или еще что-то создавать не нужно.

-- 
/ 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] [RFP]: %altrelease macro

[Vitaly Lipatov]

On 16 декабря 2007, Alexander Bokovoy wrote:
> Задумал я облегчить сборку пакетов в среде установленного
> дистрибутива и для репозитариев updates/backports. У нас есть
...
> Это означает, что спек-файл пакета на самом деле претерпевает
> определенные изменения (по меньшей мере, тэг Release) и
> фактически вынуждает поддерживать две версии пакета даже в том
Кроме случая использования для бэкпортирования команды вида
$ rpmbph -n -M30 package.spec
Команда генерирует временный спек, в который вносятся не только 
изменения релиза, но также заменяются сборочные и установочные 
зависимости, если для целевой платформы они отличны от Сизифа.
При запуске в среде системы, отличной от ALT Linux, rpmbph 
преобразует спек в вид, подходящий для целевой системы.

> случае, когда никаких других изменений в пакет не вносится.




-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] [RFP]: %altrelease macro

[Michael Shigorin]

On Sun, Dec 16, 2007 at 11:25:36PM +0300, Alexander Bokovoy wrote:
> > Однако в altlinux-release есть не только скрипт, но и файл
> > конфигурации, от которого зависит результат работы скрипта.
> > Получается, что для получения правильного результата в любом
> > случае нужно создавать hasher chroot с нужной версией
> > altlinux-release и выполнять раскрытие макросов там;
> > теоретически можно попытаться это сделать, но это не
> > вписывается в текущую логику работы gear (где --hasher - это
> > только один из возможных режимов работы).  Что делать,
> > например, с gear --describe?
> Файл конфигурации описывает именно текущую систему,
> предполагается, что он не будет изменяться пользователем, а
> будет приходить в систему с ее установкой (обновлением). То
> есть, можно считать, что это одно из свойств системы, в которой
> рассматривается пакет, поэтому специально никакой чрут или еще
> что-то создавать не нужно.

Так что, получается что-то придумать в итоге?

Мне тоже интересно, но о проблемах gear только читал по диагонали
раньше (пока что-то утряхивается, в чём не понимаешь, проще не
смотреть вообще -- меньше спрашивать в сумме ко времени, когда 
будет применимо :).

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

Re: [devel] [RFP]: %altrelease macro

[Michael Shigorin]

уточнение:

> Мне тоже интересно, но о проблемах

разработки

> gear

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

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Michael Shigorin пишет:
> On Sun, Dec 16, 2007 at 11:25:36PM +0300, Alexander Bokovoy wrote:
>>> Однако в altlinux-release есть не только скрипт, но и файл 
>>> конфигурации, от которого зависит результат работы скрипта. 
>>> Получается, что для получения правильного результата в любом 
>>> случае нужно создавать hasher chroot с нужной версией 
>>> altlinux-release и выполнять раскрытие макросов там; теоретически
>>> можно попытаться это сделать, но это не вписывается в текущую
>>> логику работы gear (где --hasher - это только один из возможных
>>> режимов работы).  Что делать, например, с gear --describe?
>> Файл конфигурации описывает именно текущую систему, предполагается,
>> что он не будет изменяться пользователем, а будет приходить в
>> систему с ее установкой (обновлением). То есть, можно считать, что
>> это одно из свойств системы, в которой рассматривается пакет,
>> поэтому специально никакой чрут или еще что-то создавать не нужно.
> 
> Так что, получается что-то придумать в итоге?
К сожалению, я пока никакой дополнительной аргументации от разработчиков
gear не видел.

> Мне тоже интересно, но о проблемах gear только читал по диагонали 
> раньше (пока что-то утряхивается, в чём не понимаешь, проще не 
> смотреть вообще -- меньше спрашивать в сумме ко времени, когда будет
> применимо :).
Это не всегда верно...

-- 
/ 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] [RFP]: %altrelease macro

[Dmitry V. Levin]

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

On Sun, Jan 20, 2008 at 08:05:37PM +0300, Alexander Bokovoy wrote:
> Michael Shigorin пишет:
> > On Sun, Dec 16, 2007 at 11:25:36PM +0300, Alexander Bokovoy wrote:
> >>> Однако в altlinux-release есть не только скрипт, но и файл 
> >>> конфигурации, от которого зависит результат работы скрипта. 
> >>> Получается, что для получения правильного результата в любом 
> >>> случае нужно создавать hasher chroot с нужной версией 
> >>> altlinux-release и выполнять раскрытие макросов там; теоретически
> >>> можно попытаться это сделать, но это не вписывается в текущую
> >>> логику работы gear (где --hasher - это только один из возможных
> >>> режимов работы).  Что делать, например, с gear --describe?
> >> Файл конфигурации описывает именно текущую систему, предполагается,
> >> что он не будет изменяться пользователем, а будет приходить в
> >> систему с ее установкой (обновлением). То есть, можно считать, что
> >> это одно из свойств системы, в которой рассматривается пакет,
> >> поэтому специально никакой чрут или еще что-то создавать не нужно.
> > 
> > Так что, получается что-то придумать в итоге?
> К сожалению, я пока никакой дополнительной аргументации от разработчиков
> gear не видел.

Насколько я помню, предлагалось реализовать макрос, который бы
модифицировал номер релиза пакета в зависимости от содержания файлов в
каталоге /etc/rpm/macros.d/
Соответственно, проблема в том, что это сильно затрудняет сборку
srpm-пакета в чужой среде, например, пакет для 4.0 в среде Сизифа.


-- 
ldv

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

Re: [devel] gear questions (was: [RFP]: %altrelease macro)

[Alexey Gladkov]

Alexander Bokovoy wrote:
>> Так что, получается что-то придумать в итоге?
> К сожалению, я пока никакой дополнительной аргументации от разработчиков
> gear не видел.
> 

Я из контекста письма не очень понял о чём речь. Раз уж начат новый
тред, можно ли узнать подробнее рассказать о сути проблемы?

P.S. Извините, возможно это где-то звучало, но я не смог найти.

-- 
Rgrds, legion

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Dmitry V. Levin пишет:
>>>> Файл конфигурации описывает именно текущую систему,
>>>> предполагается, что он не будет изменяться пользователем, а
>>>> будет приходить в систему с ее установкой (обновлением). То
>>>> есть, можно считать, что это одно из свойств системы, в которой
>>>> рассматривается пакет, поэтому специально никакой чрут или еще
>>>> что-то создавать не нужно.
>>> Так что, получается что-то придумать в итоге?
>> К сожалению, я пока никакой дополнительной аргументации от
>> разработчиков gear не видел.
> 
> Насколько я помню, предлагалось реализовать макрос, который бы 
> модифицировал номер релиза пакета в зависимости от содержания файлов
> в каталоге /etc/rpm/macros.d/ Соответственно, проблема в том, что это
> сильно затрудняет сборку srpm-пакета в чужой среде, например, пакет
> для 4.0 в среде Сизифа.
Каким образом? См. первую цитату выше, во всех средах, под которые мы
собираем, будет этот макрос, включенный в altlinux-release. То есть, во
всех чрутах сборки, которые гененрируются для сборки под эти среды, он
будет присутствовать и именно тот, который соответствует этой среде. Чем
это сильно затрудняет сборку?

Без чрута, соответствующего среде, мы не можем собрать пакет, который
будет предназначен для этой среды, если только мы опять не откажемся от
четкого контроля зависимостей и замыкания по среде исполнения.
-- 
/ 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] gear questions

[Alexander Bokovoy]

Alexey Gladkov пишет:
> Alexander Bokovoy wrote:
>>> Так что, получается что-то придумать в итоге?
>> К сожалению, я пока никакой дополнительной аргументации от разработчиков
>> gear не видел.
>>
> 
> Я из контекста письма не очень понял о чём речь. Раз уж начат новый
> тред, можно ли узнать подробнее рассказать о сути проблемы?
Новый тред не начинался, старый имеет ровно то название, которое у него 
было (%altrelease macro).

> P.S. Извините, возможно это где-то звучало, но я не смог найти.
См. первое письмо от 16 декабря 2007.

-- 
/ 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] [RFP]: %altrelease macro

[Kirill A. Shutemov]

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

On [Sun, 20.01.2008 20:21], Alexander Bokovoy wrote:
> Dmitry V. Levin пишет:
> >>>> Файл конфигурации описывает именно текущую систему,
> >>>> предполагается, что он не будет изменяться пользователем, а
> >>>> будет приходить в систему с ее установкой (обновлением). То
> >>>> есть, можно считать, что это одно из свойств системы, в которой
> >>>> рассматривается пакет, поэтому специально никакой чрут или еще
> >>>> что-то создавать не нужно.
> >>> Так что, получается что-то придумать в итоге?
> >> К сожалению, я пока никакой дополнительной аргументации от
> >> разработчиков gear не видел.
> > 
> > Насколько я помню, предлагалось реализовать макрос, который бы 
> > модифицировал номер релиза пакета в зависимости от содержания файлов
> > в каталоге /etc/rpm/macros.d/ Соответственно, проблема в том, что это
> > сильно затрудняет сборку srpm-пакета в чужой среде, например, пакет
> > для 4.0 в среде Сизифа.
> Каким образом? См. первую цитату выше, во всех средах, под которые мы
> собираем, будет этот макрос, включенный в altlinux-release. То есть, во
> всех чрутах сборки, которые гененрируются для сборки под эти среды, он
> будет присутствовать и именно тот, который соответствует этой среде. Чем
> это сильно затрудняет сборку?
> 
> Без чрута, соответствующего среде, мы не можем собрать пакет, который
> будет предназначен для этой среды, если только мы опять не откажемся от
> четкого контроля зависимостей и замыкания по среде исполнения.

gear --hasher -- это только одни из режимов работы gear.
Что должен сказать gear --describe ?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys Ltd, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] [RFP]: %altrelease macro

[Alexander Bokovoy]

Kirill A. Shutemov пишет:
> On [Sun, 20.01.2008 20:21], Alexander Bokovoy wrote:
>> Без чрута, соответствующего среде, мы не можем собрать пакет, который
>> будет предназначен для этой среды, если только мы опять не откажемся от
>> четкого контроля зависимостей и замыкания по среде исполнения.
> 
> gear --hasher -- это только одни из режимов работы gear.
> Что должен сказать gear --describe ?
То, что соответствует системе, в которой он запускается.

-- 
/ 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] [RFP]: %altrelease macro

[Dmitry V. Levin]

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

On Sun, Jan 20, 2008 at 08:21:13PM +0300, Alexander Bokovoy wrote:
> Dmitry V. Levin пишет:
> >>>> Файл конфигурации описывает именно текущую систему,
> >>>> предполагается, что он не будет изменяться пользователем, а
> >>>> будет приходить в систему с ее установкой (обновлением). То
> >>>> есть, можно считать, что это одно из свойств системы, в которой
> >>>> рассматривается пакет, поэтому специально никакой чрут или еще
> >>>> что-то создавать не нужно.
> >>> Так что, получается что-то придумать в итоге?
> >> К сожалению, я пока никакой дополнительной аргументации от
> >> разработчиков gear не видел.
> > 
> > Насколько я помню, предлагалось реализовать макрос, который бы 
> > модифицировал номер релиза пакета в зависимости от содержания файлов
> > в каталоге /etc/rpm/macros.d/ Соответственно, проблема в том, что это
> > сильно затрудняет сборку srpm-пакета в чужой среде, например, пакет
> > для 4.0 в среде Сизифа.
> Каким образом? См. первую цитату выше, во всех средах, под которые мы
> собираем, будет этот макрос, включенный в altlinux-release. То есть, во
> всех чрутах сборки, которые гененрируются для сборки под эти среды, он
> будет присутствовать и именно тот, который соответствует этой среде. Чем
> это сильно затрудняет сборку?

Есть некоторые операции, для выполнения которых надо знать номер релиза.
В частности, это все операции gear, в которых может происходить подстановка
@release@, а ведь их много.  В некоторых случаях отказаться от
использования номера релиза неудобно, например, в правилах tar и diff для
.gear/rules, и в gear-create-tag.

> Без чрута, соответствующего среде, мы не можем собрать пакет, который
> будет предназначен для этой среды, если только мы опять не откажемся от
> четкого контроля зависимостей и замыкания по среде исполнения.

Речь идёт о том, что %altrelease существенно осложняет процедуру отправки
пакета на сборку.


-- 
ldv

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