Если в 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: Нормальная сборка пакета
Из свеженького: [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
apt-get install rpm-build-licenses
[mutabor@builder meld-1.1.5.1]$ apt-get install rpm-build-licenses E: Запись в /var/cache/apt/ невозможна E: Невозможно прочитать список пакетов или файл статуса.
apt-get вызывать из-под суперпользователя, конечно :)
Под root: su - перед этой командой
Представьте, я знаю ;) Но, во-первых, в данном случае у меня нет такой возможности, а во-вторых, rpmbsh для того и нужен, чтобы собирать пакет на основании спека без привилегий суперпользователя. Как root я могу просто поставить нужные пакеты в основную систему и не заморачиваться с rpmbsh.
Да, это такой недостаток rpmbsh (пакет собирается без всяких ухищрений в хост-системе). Я так понимаю особого решения, кроме применённого в gear, нет.
Я слышал, что hasher может собирать пакет не из .src.rpm, а из .pkg.tar, на этапе создания которого зависимости не нужны. Может быть, в etersoft-build-utils имеет смысл реализовать эту функциональность?
Я бы, кстати, с удовольствием увидел в etersoft-build-utils аналог rpmbsh для git-репозиториев. Как вариант, обучить rpmbsh работать с git-репозиториями.
Дык сто лет как уже.
Да, Денис Смирнов давно прикрутил. Замечания принимаются. Особо отмечу, что принципы работы с rpmbb/bsh не меняются, спек указывать надо по-прежнему, несмотря на то, что при работе с git это как бы не нужно.
А в принципе возможно ли следующее: на основании спека создаётся .pkg.tar (не обязательно при работе с git), и он скармливается хэшеру? Это помогло бы (возможно, не в 100%, но уж в 90%-то точно) решить проблему с неопределёнными на этапе сборки исходного пакета макросами.
Насколько я понял именно так и собирается пакет с помощью $ gear --hasher -- hsh Эта команда как раз и занимается созданием .pkg.tar, который скармливает хешеру Кстати, проблемы с зависимостями могут быть двух видов... Для сборки пакета из src.rpm и для сборки самого src.rpm... И тут есть интересная особенность... Дело в том, что rpm не всегда способен собрать правильный src.rpm без некого минимального набора пакетов... Этот минимальный набор иногда требует расширения... Для этого существует BuildRequires(pre) зависимости... На самом деле gear --hasher удовлетворяет большинству задумок... В этом плане у rpmbsh есть существенный недостаток - он собирает src.rpm-пакет на хостовой системе. А это надо выполнять в чруте, как hasher собственно и делает при передаче ему некого .pkg.tar
Может быть меня кто-нибудь научит делать .pkg.tar и мы модернизируем rpmbsh?
(In reply to comment #14) > Может быть меня кто-нибудь научит делать .pkg.tar > и мы модернизируем rpmbsh? Это такой tar, в котором все исходники и spec. Возможно еще заголовок тома совпадает с именем spec-файла. Только как из spec'а узнать все исходники? gear'e их прямо указывают отдельно, а вот без него я думаю никак.
Может быть просто делать его из того cpio, который в src.rpm?
(In reply to comment #16) > Может быть просто делать его из того cpio, который в src.rpm? Если есть src.rpm, то его можно собрать. Если я правильно понял, то именно в создании его проблема и заключается. Эта задача в общем случае не разрешима в принципе. Собрать rpm можно только при удовлетворении всех зависимостей. gear это делает, ставя все зависимости в hasher, а затем копируя туда все исходники, которые ему явно указаны и spec. А затем уже собирая их там. Рекомендую просто использовать gear. В принципе, задачу можно решить дополнительно указывая список исходников, скажем по одному на строку в файле. Темы связанные с этим обсуждались в devel, так что я практически уверен, что другого решения нет.
(In reply to comment #17) > Собрать rpm можно только при удовлетворении всех зависимостей. Но собрать src.rpm можно не имея всех зависимостей, и об этом речь.
(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.
Можно (поначалу) даже упростить подход. Всё равно при этом класс собираемых с помощью rpmbsh пакетов существенно расширится по сравнению с текущим состоянием. Для этого сначала с помощью rpm -bE получаем спек с (возможно недо)раскрытыми макросами. Если видим, что все Source и Patch раскрылись (что сработает в 99% случав, если не больше), то создаём chroot, копируем туда исходники и спек и запускаем hasher. Если не раскрылись, то интеллигентно ругаемся на то, что "данный пакет невозможно собрать с помощью rpmbsh в текущем сборочном окружении".
(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% случаев.
Что в версии 1.5.1?
Да, теперь всё работает :) Спасибо!
Раз работает, закрываю.
