Bug 8579

Created attachment 1270 [details]
testcase specfile

Приаттачиваю спек, показывающий описанную проблему.

Это не проблема hasher'а, это проблема spec-файлов, которые используют макросы,
отсутствующие в базовой сборочной среде.
Средствами hasher'а этого никак не исправить.

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

(In reply to comment #2)
> Это не проблема hasher'а, это проблема spec-файлов, которые используют макросы,
> отсутствующие в базовой сборочной среде.

Однако сами спеки обеспечивают соответствующие BuildRequires и собираюися даже в
хэшере.

> Средствами hasher'а этого никак не исправить.

Для данного случая, наверно, да... здесь эдакий race возникает... для работы
макросов надо установить зависимые пакеты, а для вычисления зависимостей надо
перепаковать пакет...
Здесь даже не имеет значение - обернута ли зависимость на пакет или нет, верно?

А сменить error на warning (для данного этапа) здесь не прокатит?

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

В настоящее время это уже становится проблематично. Коль скоро у нас есть
/etc/rpm/macros.d/, слишком много пакетов хотят туда макросы складывать... Как
можно обеспечить нахождение всех необходимых пакетов в сборочной среде (даже
если макросы будут паковаться в отдельный(-ые) пакерт(-ы))?

Сменить error на warning можно, что я и сделаю.

Но проблему надо решать в более общем виде.

Кстати, было бы удобно также иметь warning вместо error при упаковке src.rpm.
Суть в том, чтобы запаковать src.rpm c --nodeps и отправить на сборку в хэшер.
Сейчас же нужно иметь установленными зависимые devel пакеты только для того,
чтобы собрать src.rpm

С последним комментарием не согласен.
Возиожность обнаружения ошибок уже на стадии -bs очень полезна.
Кому надо, может использовать -bs --define '_allow_undefined_macros 1'.

Ок, возьмем на вооружение (в запас) такую конструкцию :)

Всё, что можно было сделать в рамках hasher, я сделал в 1.0.26-alt1.

Похоже, на это же напоролся с бутстрапом pam_mktemp-1.1.1-alt3.src.rpm:

--- ~/.hasher/config
# ...
rpmargs='--disable selinux'
repackage_source=1
---

http://git.altlinux.org/gears/p/pam_mktemp.git?p=pam_mktemp.git;a=blob;f=pam_mktemp.spec содержит такой фрагмент:

---
%def_enable selinux

# due to PAM policy.
BuildRequires(pre): libpam-devel
# ...
%{?_enable_selinux:BuildRequires: libselinux-devel}

%set_pam_name %name
---

libpam0-devel зависит от rpm-macros-pam0, где и определяется %set_pam_name.

Вывод при попытке сборки получается такой:

warning: Macro %set_pam_name not found
error: line 24: Unknown tag: %set_pam_name pam_mktemp
hsh-rebuild: pam_mktemp-1.1.1-alt3.src.rpm: failed to fetch build dependencies.

(В ответ на комментарий №6)
> Кому надо, может использовать -bs --define '_allow_undefined_macros 1'.

Напоминалка: по предварительному осмотру ты высказался в том смысле, что код разбора зависимостей, написанный позже для gear, можно попробовать адаптировать для hsh-rebuild.

Спасибо, почти совсем добито в hasher-1.3.28-alt1:
http://git.altlinux.org/gears/h/hasher.git?p=hasher.git;a=commit;h=a9596508244ad42c686c989e7e02b6dcd78cd896
http://git.altlinux.org/gears/h/hasher.git?p=hasher.git;a=commit;h=6daed6ed98ba5df653e5b4f4aa3ca8958abf2764

Пакеты, не собиравшиеся из srpm из-за неустановленных BuildRequires(pre), наконец-то засобирались.

Но вылезла другая проблема: перестали собираться пакеты с отключением ручек, включенных по умолчанию -- например, libcap-ng-0.7.4-alt1.2, где вкорячил %def_with python3 и соответствующую отключалку, при наличии в ~/.hasher/config записи rpmargs='--without python3' всё равно пытается запросить для сборки rpm-build-python3 и обламывается, потому как на e2k его пока нет -- см. тж.:
http://git.altlinux.org/gears/l/libcap-ng.git?p=libcap-ng.git;a=blob;f=libcap-ng.spec;h=fc23c3b9e287fd89dd46802a576ad748809ebe33;hb=a744ec8fe8fa9cbcb33ad6dada6bf8450df70b71

Возможно ли починить ещё и это? :)

PS: для gear-hsh там же теперь наблюдается такое же поведение.

Не, всё правильно: в libcap-ng.spec и libxml2.spec неоправданно используется

BuildRequires(pre): rpm-build-python3

вместо достаточного для обеспечения раскрытия макросов в %setup, %build, %install и %files

BuildRequires: rpm-build-python3

либо

BuildPreReq: rpm-build-python3

Это избыточная строгость зависимостей, которую надо чинить в таких пакетах.
Тест: "если собирается gear-rpm -bs --nodeps, то достаточно" (именно из git).

ldv@: "BuildRequires(pre) применимо к пакетам, собирающимся из gear-репозитория, либо при помощи hsh --query-repackage".