Summary: | Плохо работает ExcludeArch/ExclusiveArch на сборочнице ppc64le | ||
---|---|---|---|
Product: | Infrastructure | Reporter: | Aleksei Nikiforov <darktemplaralt> |
Component: | girar | Assignee: | Dmitry V. Levin <ldv> |
Status: | CLOSED NOTABUG | QA Contact: | Andrey Cherepanov <cas> |
Severity: | major | ||
Priority: | P5 | CC: | glebfm, ldv |
Version: | unspecified | ||
Hardware: | ppc | ||
OS: | Linux |
Description
Aleksei Nikiforov
2020-08-17 12:38:47 MSK
(In reply to Aleksei Nikiforov from comment #0) > Есть пакет wine, который собирается только для x86_64, %ix86 и aarch64. > > В спек добавляется BuildRequires(pre): vkd3d-devel, а этот пакет также есть > только на x86_64, %ix86, aarch64 и отсутствует на ppc64le и armh. Это нарушение контракта, BuildRequires(pre) не могут быть условнымм, и в BuildRequires(pre) могут быть указаны только такие зависимости, которые удовлетворяются на каждой архитектуре. Для условных и архитектурно-зависимых следует использовать обычные BuildRequires. Тогда почему на armh ошибки нет? (In reply to Aleksei Nikiforov from comment #2) > Тогда почему на armh ошибки нет? На armh __временно__ все ошибки сборки src.rpm игнорируются, поскольку таких ошибок пока ещё слишком много. Когда архитектура дорастёт, игнорирование закончится. Тогда другой вопрос: я хочу в "Requires:" собираемого пакета добавить зависимость в виде имени пакета, содержащего определённую библиотеку. Как это можно сделать без использования "BuildRequires(pre):" с именем пакета, который содержит сам данную библиотеку или зависит от такого пакета? Я бы предпочёл такое решение, что я указываю libsomething-devel, и генерирую зависимость на libsomething$soname автоматически, а не вручную писать зависимость на libsomething$soname и постоянно менять её вручную когда $soname меняется. Т.е. на примере wine, сейчас есть libvulkan-devel, и я создаю в итоге зависимость на libvulkan1. Я бы предпочёл чтобы если когда-нибудь вместо libvulkan1 появилась бы libvulkan2, то зависимость исправлялась бы на новую простой пересборкой пакета без дополнительных изменений. К сожалению, автоматический поиск зависимостей не находит зависимости на libvulkan1. В wine часть файлов в формате PE, и я думаю их количество будет только расти. Есть ли варианты кроме создания модуля автоматического поиска зависимостей для PE файлов? (In reply to Aleksei Nikiforov from comment #4) > Тогда другой вопрос: я хочу в "Requires:" собираемого пакета добавить > зависимость в виде имени пакета, содержащего определённую библиотеку. Как > это можно сделать без использования "BuildRequires(pre):" с именем пакета, > который содержит сам данную библиотеку или зависит от такого пакета? > > Я бы предпочёл такое решение, что я указываю libsomething-devel, и генерирую > зависимость на libsomething$soname автоматически, а не вручную писать > зависимость на libsomething$soname и постоянно менять её вручную когда > $soname меняется. Если хочется использовать макрос, который на разных архитектурах раскрывается либо в ничего, либо в "Requires: libsomething$soname", то такой макрос лучше поместить в какой-нибудь пакет rpm-macros-что-нибудь. Поскольку на ppc64le всё работает как ожидается, закрываю. Буду искать другие решения своей проблемы. (Ответ для Aleksei Nikiforov на комментарий #4) > Есть ли варианты кроме создания модуля автоматического поиска зависимостей > для PE файлов? Мне кажется, что это звучит как самое хорошее решение -- смотреть в PE файлы на тему того, какие библиотеки будут грузиться вместо того, чтобы предугадывать при сборке пакета. А это сложно технически, кстати? (Ответ для Gleb F-Malinovskiy на комментарий #7) > (Ответ для Aleksei Nikiforov на комментарий #4) > > Есть ли варианты кроме создания модуля автоматического поиска зависимостей > > для PE файлов? > > Мне кажется, что это звучит как самое хорошее решение -- смотреть в PE файлы > на тему того, какие библиотеки будут грузиться вместо того, чтобы > предугадывать при сборке пакета. > А это сложно технически, кстати? Получить зависимости PE-библиотеки можно с помощью objdump+grep+awk/sed. Проблема с libvulkan.so.1 следующая: ни в одном ELF или PE файле нет зависимости на эту библиотеку. Прошёлся strings по всем файлам. Нашёл упоминание только в winex11.drv.so, но он не линкуется с libvulkan.so.1. Наверно что-то типа dlopen использует. А значит поиск зависимостей в PE файлах в данном случае не поможет. $ ldd /usr/src/tmp/wine-buildroot/usr/lib64/wine/winex11.drv.so linux-vdso.so.1 (0x00007ffcc2543000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f72929b5000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f7292873000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f729286e000) libm.so.6 => /lib64/libm.so.6 (0x00007f7292729000) libc.so.6 => /lib64/libc.so.6 (0x00007f7292565000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f729253b000) /lib64/ld-linux-x86-64.so.2 (0x00007f7292aa4000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f7292534000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f729252c000) $ strings /usr/src/tmp/wine-buildroot/usr/lib64/wine/winex11.drv.so | grep libvulkan libvulkan.so.1 libvulkan.so Да, проверил по коду, там dlopen: http://git.altlinux.org/gears/w/wine.git?p=wine.git;a=blob;f=wine/dlls/winex11.drv/vulkan.c;h=4de82586906cb8bb0cdbb9440bb40affb114c514;hb=517dd2de44b82463928f89e1c0e97485e12561dc#l107 Не думаю, что стоит для этого писать какой-либо генератор. Если выкинуть такие конструкции для vkd3d и faudio и оставить только для vulkan, то должно пройти успешно. |