Bug 15647 - rpmbsh не стартует при наличии неизвестных макросов
: rpmbsh не стартует при наличии неизвестных макросов
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/etersoft-build-utils)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2008-05-14 12:59 by
Modified: 2009-01-09 03:44 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-05-14 12:59:18
Если в spec-файле имеется макрос, определённый в одном из пакетов, от которого
зависит сборка, а в окружении, из которого запускается rpmbsh, этот пакет не
установлен, то запуск rpmbsh завершается с ошибкой, которой быть не должно, так
как в сборочной среде, создаваемой в chroot этот пакет будет установлен по
зависимостям и там этот макрос окажется определённым.Вот пример такой ситуации:

[mutabor@builder SPECS]$ rpmbsh xmms-in-modplug.spec 
Target ALT Linux system: SS, use /etc/apt/apt.conf.SS
ошибка: Macro %xmms_inputdir not found
  2<     %xmms_inputdir
ошибка: Незакрытая {: {?%xmms_inputdir
  2<     (пусто)
ошибка: xmms-in-modplug.spec:31: parseExpressionBoolean код возврата: -1
ошибка: запрос файла спецификации xmms-in-modplug.spec не удался, невозможно
разобрать файл
ошибка: Macro %xmms_inputdir not found
  2<     %xmms_inputdir
ошибка: Незакрытая {: {?%xmms_inputdir
  2<     (пусто)
ошибка: xmms-in-modplug.spec:31: parseExpressionBoolean код возврата: -1
ошибка: запрос файла спецификации xmms-in-modplug.spec не удался, невозможно
разобрать файл
add_changelog: xmms-in-modplug.spec: version "" unchanged, skipping
skip changelog editing without EDITOR var
Просто упаковывается xmms-in-modplug-2.05-alt1.3.src.rpm
Платформы для сборки: i586
Сборка для платформы i586
ошибка: Macro %xmms_inputdir not found
  2<     %xmms_inputdir
ошибка: Незакрытая {: {?%xmms_inputdir
  2<     (пусто)
ошибка: /srv/mutabor/RPM/SPECS/xmms-in-modplug.spec:31: parseExpressionBoolean
код возврата: -1
Error: Error with rpmbuild

Соответственно выдержки из xmms-in-modplug.spec:

%ifndef %xmms_inputdir
    %define xmms_inputdir %(xmms-config --input-plugin-dir)
%endif

и далее:

%install
%make bindir=%buildroot%_bindir \
plugindir=%buildroot%xmms_inputdir install

%files
%xmms_inputdir/*.so 
Steps to Reproduce:
1. Скачать их Сизифа пакет с исходниками xmms-in-modplug
2. Установить пакет
3. В каталоге со спеками выполнить rpmbsh xmms-in-modplug.spec
Actual Results:  
Приведённая выше ошибка

Expected Results:  
Нормальная сборка пакета
------- Comment #1 From 2008-05-27 11:51:31 -------
Из свеженького:

[mutabor@builder SPECS]$ rpmbsh meld.spec 
Target ALT Linux system: SS, use /etc/apt/apt.conf.SS
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

ошибка: запрос файла спецификации meld.spec не удался, невозможно разобрать файл
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

ошибка: запрос файла спецификации meld.spec не удался, невозможно разобрать файл
add_changelog: meld.spec: version "" unchanged, skipping
skip changelog editing without EDITOR var
Просто упаковывается meld-1.1.5.1-alt2.qa1.src.rpm
Платформы для сборки: i586
Сборка для платформы i586
ошибка: Macro %gpl2plus not found
ошибка: строка 9: License: %gpl2plus

Error: Error with rpmbuild
------- Comment #2 From 2008-05-27 12:51:59 -------
apt-get install rpm-build-licenses
------- Comment #3 From 2008-05-27 13:52:33 -------
[mutabor@builder meld-1.1.5.1]$ apt-get install rpm-build-licenses
E: Запись в /var/cache/apt/ невозможна
E: Невозможно прочитать список пакетов или файл статуса.
------- Comment #4 From 2008-05-27 13:54:12 -------
apt-get вызывать из-под суперпользователя, конечно :)
------- Comment #5 From 2008-05-27 14:23:09 -------
Под root: 
su -
перед этой командой
------- Comment #6 From 2008-05-27 14:57:20 -------
Представьте, я знаю ;) Но, во-первых, в данном случае у меня нет такой
возможности, а во-вторых, rpmbsh для того и нужен, чтобы собирать пакет на
основании спека без привилегий суперпользователя. Как root я могу просто
поставить нужные пакеты в основную систему и не заморачиваться с rpmbsh.
------- Comment #7 From 2008-05-28 00:12:04 -------
Да, это такой недостаток rpmbsh (пакет собирается без всяких ухищрений в 
хост-системе).
Я так понимаю особого решения, кроме применённого в gear, нет.
------- Comment #8 From 2008-05-28 10:44:44 -------
Я слышал, что hasher может собирать пакет не из .src.rpm, а из .pkg.tar, на
этапе создания которого зависимости не нужны. Может быть, в
etersoft-build-utils
имеет смысл реализовать эту функциональность?
------- Comment #9 From 2008-05-28 16:03:23 -------
Я бы, кстати, с удовольствием увидел в etersoft-build-utils аналог rpmbsh для
git-репозиториев. Как вариант, обучить rpmbsh работать с git-репозиториями.
------- Comment #10 From 2008-05-28 16:22:56 -------
Дык сто лет как уже.
------- Comment #11 From 2008-05-28 23:25:45 -------
Да, Денис Смирнов давно прикрутил. Замечания принимаются.
Особо отмечу, что принципы работы с rpmbb/bsh не меняются, 
спек указывать надо по-прежнему, несмотря на то, что при работе с git
это как бы не нужно.
------- Comment #12 From 2008-05-29 11:51:25 -------
А в принципе возможно ли следующее: на основании спека создаётся .pkg.tar (не
обязательно при работе с git), и он скармливается хэшеру? Это помогло бы
(возможно, не в 100%, но уж в 90%-то точно) решить проблему с неопределёнными
на
этапе сборки исходного пакета макросами.
------- Comment #13 From 2008-05-29 18:17:22 -------
Насколько я понял именно так и собирается пакет с помощью
 $ gear --hasher -- hsh
Эта команда как раз и занимается созданием .pkg.tar, который скармливает хешеру

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

И тут есть интересная особенность... Дело в том, что rpm не всегда способен
собрать правильный src.rpm без некого минимального набора пакетов... Этот
минимальный набор иногда требует расширения... Для этого существует
BuildRequires(pre) зависимости...

На самом деле gear --hasher удовлетворяет большинству задумок... В этом плане у
rpmbsh есть существенный недостаток - он собирает src.rpm-пакет на хостовой
системе. А это надо выполнять в чруте, как hasher собственно и делает при
передаче ему некого .pkg.tar
------- Comment #14 From 2008-05-30 09:55:45 -------
Может быть меня кто-нибудь научит делать .pkg.tar
и мы модернизируем rpmbsh?
------- Comment #15 From 2008-05-30 11:33:17 -------
(In reply to comment #14)
> Может быть меня кто-нибудь научит делать .pkg.tar
> и мы модернизируем rpmbsh?

Это такой tar, в котором все исходники и spec. Возможно еще заголовок тома 
совпадает с именем spec-файла. Только как из spec'а узнать все исходники? 
gear'e их прямо указывают отдельно, а вот без него я думаю никак.
------- Comment #16 From 2008-05-31 02:12:32 -------
Может быть просто делать его из того cpio, который в src.rpm?
------- Comment #17 From 2008-05-31 18:33:59 -------
(In reply to comment #16)
> Может быть просто делать его из того cpio, который в src.rpm?

Если есть src.rpm, то его можно собрать. Если я правильно понял, то именно в 
создании его проблема и заключается.
Эта задача в общем случае не разрешима в принципе. Собрать rpm можно только при 
удовлетворении всех зависимостей. gear это делает, ставя все зависимости в 
hasher, а затем копируя туда все исходники, которые ему явно указаны и spec. А 
затем уже собирая их там. Рекомендую просто использовать gear. В принципе, 
задачу можно решить дополнительно указывая список исходников, скажем по одному 
на строку в файле. Темы связанные с этим обсуждались в devel, так что я 
практически уверен, что другого решения нет.
------- Comment #18 From 2008-06-01 00:25:19 -------
(In reply to comment #17)
> Собрать rpm можно только при удовлетворении всех зависимостей.
Но собрать src.rpm можно не имея всех зависимостей, и об этом речь.
------- Comment #19 From 2008-06-01 09:40:53 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Собрать rpm можно только при удовлетворении всех зависимостей.
> Но собрать src.rpm можно не имея всех зависимостей, и об этом речь.

Хорошо. Описываю проблему, как я ее вижу подробнее.
Необходимо собрать пакет по спеку и исходникам в системе, в которой не стоят 
все зависимости, используя hasher.
Для этого hasher'у надо передать спек и все исходники, больше ему ничего не 
надо. Спек мы знаем, остаются исходники. Чаще всего их можно взять из спека, но 
в некоторых пакетах при указании исходников используются макросы (например в 
kdebase). Чаще всего это %version. Такое можно решить выполнив часть работы с 
помощью утилит hasher'а. Но некоторые используют и более хитрые макросы, для 
раскрытия которых, необходимы некоторые пакеты предоставляющие макросы. При 
этом эти пакеты могут даже стоять в системе, но быть не тех версий, которые 
вытянет hasher потом. В частности мы наблюдали такие проблемы в системе, где 
установлен python-2.4, тогда как в сизифе -- python-2.5.
Таким образом работать со спеком возможно только в том стиле, которыйя описал в 
своем сообщении http://lists.altlinux.org/pipermail/devel/2008-May/074855.html. 
То есть, надо изначально создавать окружение для пакета, потом копировать туда 
спек и анализировать зависимости уже внутри hasher. Затем надо опять-таки 
внутри hasher выяснять все исходники для пакета и только затем собирать pkg.tar 
по полученной информации (при этом, чтобы не собирать окружение заново, 
пользоваться надо утилитой hsh-rebuild). Правда его можно не собирать, а просто 
скопировать исходники в .in и выполнить команды для сборки с помощью hsh-run.
------- Comment #20 From 2008-06-02 18:14:31 -------
Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с
помощью rpmbsh пакетов существенно расширится по сравнению с текущим
состоянием.
Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми
макросами. Если видим, что все Source и Patch раскрылись (что сработает в 99%
случав, если не больше), то создаём chroot, копируем туда исходники и спек и
запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что
"данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном
окружении".
------- Comment #21 From 2008-06-02 23:36:44 -------
(In reply to comment #20)
> Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с
> помощью rpmbsh пакетов существенно расширится по сравнению с текущим 
> состоянием.
> Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми
> макросами.

Ну, вот в этом-то вся и проблема... сборочные зависимости таким образом ставятся
в сам сборочный сервер, причём какие они потребуются для раскрытия макросов
заранее неизвестно... При первоначальном разворачивании процесс начинается с
того, что в систему, по мере необходимости, ставят кучу пакетов... Далее это
может привести к конфликтам, когда всё что нужно для сборки разных пакетов в
систему не устанавливается...

> Если видим, что все Source и Patch раскрылись (что сработает в 99%
> случав, если не больше), то создаём chroot, копируем туда исходники и спек и
> запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что
> "данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном
> окружении".

Я так понимаю, что rpmbsh, в данном случае, расматривается, как средство работы
из стандартной сборочной среды RPM (~/RPM/{BUILD,RPMS,SOURCES,SPECS,SRPMS}). И
вышеописанное поведение в таком случае оправдано...

Просто получается, что rpmbsh выступает, как более универсальное средство, чем
gear. Менее надёжное в плане организации универсальной сборочной среды, но более
удобное...

Хотелось бы это подчеркнуть, поскольку rpmbsh можно использовать как для
обычного SPEC-файла в сборочном каталоге RPM, так и для gear-репозитория. В этом
плане, раз уж внутренние механизмы по этому поводу раличаются, я думаю стоит
сохранить для gear стандартную схему (без разворачивания SPEC-файла) - это
позволит, не задумываясь о последствиях, использовать rpmbsh вместо gear
--hasher. Для обычной сборки, из сборочного каталога RPM, вышеописанная схема
действительно является достаточной в 95% случаев. 
------- Comment #22 From 2008-12-28 01:58:45 -------
Что в версии 1.5.1?
------- Comment #23 From 2008-12-31 16:41:31 -------
Да, теперь всё работает :) Спасибо!
------- Comment #24 From 2009-01-09 03:37:42 -------
Раз работает, закрываю.