38919 2020-09-10 17:25:20 +0300 Сборочница не должна пропускать в noarch пакеты с excludearch или exclusivearch 2026-02-05 11:03:03 +0300 1 1 4 Development Sisyphus rpm-build unstable x86_64 Linux NEW https://bugzilla.altlinux.org/show_bug.cgi?id=42121 P5 normal --- 1 darktemplaralt vseleznv antohami arseny asheplyakov asy glebfm imz iv klark lav ldv mike placeholder ruslandh shaba vseleznv vt qa-sisyphus oldest_to_newest 192369 0 darktemplaralt 2020-09-10 17:25:20 +0300 Если у пакета есть ExcludeArch или ExclusiveArch, то он не должен быть noarch. Как минимум, если он не собирается на всех основных архитектурах сборочницы. В таком случае следует сборку задания завершать с ошибкой с соответствующим сообщением. Иначе пакет появляется даже на тех архитектурах, сборку на которых явно выключили. См. также: https://bugzilla.altlinux.org/show_bug.cgi?id=38916#c3 192371 1 vseleznv 2020-09-10 18:08:55 +0300 Я думаю, эту проверку надо сделать в rpm-build. 192372 2 darktemplaralt 2020-09-10 18:31:04 +0300 (Ответ для Vladimir D. Seleznev на комментарий #1) > Я думаю, эту проверку надо сделать в rpm-build. Где-то она уже реализована: http://git.altlinux.org/tasks/archive/done/_251/257824/logs/events.1.2.log warning (#100): i586: non-verifiable noarch packages due to ExclusiveArch warning (#100): armh: non-verifiable noarch packages due to ExclusiveArch Возможно будет достаточно превратить эти предупреждения в ошибки. 192385 3 iv 2020-09-11 08:10:54 +0300 Идею поддерживаю, но вообще очень интересен список потенциально пострадавших пакетов. Простой grep по спекам показывает, что таких может быть немало -- хотя как совсем правильно грепать неясно. Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их сборку кроссом? Мне бы для mipsel пригодилось =) 192387 4 ldv 2020-09-11 08:56:02 +0300 (In reply to Ivan A. Melnikov from comment #3) > очень интересен список потенциально пострадавших > пакетов. Простой grep по спекам показывает, что таких может быть немало -- > хотя как совсем правильно грепать неясно. > > Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их > сборку кроссом? Мне бы для mipsel пригодилось =) +100500 Это PreReq к началу обусждения. 192396 5 darktemplaralt 2020-09-11 10:31:56 +0300 Грубая оценка: $ git clone https://github.com/vt-alt/specs $ cd specs $ $ git grep -l noarch | xargs egrep -l -i 'exclusivearch|excludearch' | cut -d / -f 2 389-ds-base Inventor R-base adobe-flash-player alsaplayer aqsis atlas bcc camotics cegui ceph cgal crtools doxygen dpdk edk2-aarch64 edk2-rpi edk2-tools edk2 electron etersoft-build-utils exodusii firefox firmware-intel-ucode fpc freeipa-healthcheck frogatto fwupd fzf gcc4.3 gcc4.4 gcc4.5 gcc4.6 gcc4.7 gcc4.8 gcc4.9 gdb gens-gs glusterfs7 gnustep-Lynkeos gnustep-gorm gnustep-sqlclient golang-golang-x-crypto golang-golang-x-net golang-golang-x-sys golang-tools golang-torproject-pluggable-transports-goptlib golang gprolog hedgewars igt-gpu-tools indilib installer-feature-bootloader-grub iptables ipxe java-1.7.0-openjdk java3d jicofo jitsi-videobridge jogl kbd kcov keepass kernel-headers-common kernel-image-ovz-el7 kernel-image-rpi-def kernel-image-rpi-un kernel-image-rt kernel-image-std-debug kernel-image-std-def kernel-image-std-pae kernel-image-un-def kernel-source-bcmwl kernel-source-lkrg kernel-src-vboxguest kernel-src-vboxhost knot-resolver kodi libcrystalhd libmirisdr liboil libsmbios lilo linuxcnc livecd-qemu-arch lsb-init lsb lsp-plugins lxd maven-eclipse-plugin maxima mcelog mkve mnemosyne mysql-workbench-community netgen ngsolve nvidia_glx_src openbios opencpn opendx openjfx openni openqa openshot opensnitch opentoonz openvswitch pcsx2 perl-Mozilla-LDAP perl-libnet pesign-test-certs podman ppsspp prometheus publican-jboss pve-docs python3-module-PyQtWebEngine python3-module-jetson-gpio qboot qt5-webengine qtiplot racket reflections riot-desktop rpm-build-vm seabios seamonkey skiboot skype-userinstall springrts sweethome3d syslinux tcc teeworlds tremulous-data virtualbox vmware-view-preinstall vmware-view-userinstall vzctl warsow-data webtorrent-desktop wine-gecko wine-vanilla wine winetricks xen xenomai xtables-addons ztnbatch Думаю, в большей части из них сейчас проблема со всякой документацией или noarch питоновскими модулями будет. Тут упоминались уже qboot и seabios. С какими ещё пакетами из этого списка могут быть проблемы? 192404 6 mike 2020-09-11 11:51:22 +0300 (Ответ для Vladimir D. Seleznev на комментарий #1) > Я думаю, эту проверку надо сделать в rpm-build. +1 Пару раз уже намучился, пока заметил "BuildArch: noarch" в _основном_ пакете. Думаю, "мягкий вариант" может выглядеть как-то так: 1) сделать проверку/warning в rpm-build; 2) заслать в devel@ список из comment 5, по важным пакетам вроде doxygen после ручного отсева (например, %ifarch на флаги компилятора и noarch с -data или -doc) развесить баги или сразу готовить NMU; 3) поработать над важными пакетами и дать остальным заметить предупреждения; 4) в следующем году переключить warning в error либо в rpm-build, либо на сборочнице. Для начала оформил installer-feature-bootloader-grub с таким %changelog: - It's not noarch if ExclusiveArch: is specified (see also #38919) PS: не совсем понятно, что с BuildArch: подпакетов. Возможно, такие случаи стоит оставлять как warning, поскольку делать какой-нибудь собираемый из того же архива -data noarch'ем, лишь бы угодить сборочнице, будет контрпродуктивно. PPS: более взвешенное решение, чем основанное на анализе спека, стоило бы принимать на основании сверки не только состава, но и зависимостей (R:/BR:) в плане их наличия на целевых платформах (но это только в сборочнице). 192433 7 shaba 2020-09-12 01:20:04 +0300 Кто-то грозился переделать cross-gcc по-правильному. Как он появится, можно и эту багу решать. Я на ExclusiveArch для edk2 и т.п. не от хорошей жизни перешел. 192445 8 vseleznv 2020-09-13 01:50:40 +0300 (In reply to Ivan A. Melnikov from comment #3) > Идею поддерживаю, но вообще очень интересен список потенциально пострадавших > пакетов. Простой grep по спекам показывает, что таких может быть немало -- > хотя как совсем правильно грепать неясно. > > Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их > сборку кроссом? Мне бы для mipsel пригодилось =) Какой интересный случай. Да, такие пакеты надо бы кросс-компилятором собирать, надо бы починить кросс-компилятор, но кто бы занялся? (In reply to Michael Shigorin from comment #6) > (Ответ для Vladimir D. Seleznev на комментарий #1) > > Я думаю, эту проверку надо сделать в rpm-build. > +1 > > Пару раз уже намучился, пока заметил "BuildArch: noarch" в _основном_ пакете. > > Думаю, "мягкий вариант" может выглядеть как-то так: > 1) сделать проверку/warning в rpm-build; Начать с ворнинга — хорошая мысль. > 2) заслать в devel@ список из comment 5, по важным пакетам вроде doxygen > после ручного отсева (например, %ifarch на флаги компилятора и noarch > с -data или -doc) развесить баги или сразу готовить NMU; > 3) поработать над важными пакетами и дать остальным заметить предупреждения; > 4) в следующем году переключить warning в error либо в rpm-build, > либо на сборочнице. > > Для начала оформил installer-feature-bootloader-grub с таким %changelog: > > - It's not noarch if ExclusiveArch: is specified (see also #38919) > > PS: не совсем понятно, что с BuildArch: подпакетов. Возможно, такие случаи > стоит оставлять как warning, поскольку делать какой-нибудь собираемый из > того же архива -data noarch'ем, лишь бы угодить сборочнице, будет > контрпродуктивно. Наверное, для подпакетов стоит оставить возможность BuildArch: noarch. 192453 9 klark 2020-09-14 05:11:59 +0300 Лет шесть назад было аналогичное обсуждение у Федоры: https://pagure.io/packaging-committee/issue/355 которое вылилось в некую встречу, по результату которой формализовали вот что: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies 195998 10 asy 2021-02-03 19:56:47 +0300 (In reply to Aleksei Nikiforov from comment #0) > Если у пакета есть ExcludeArch или ExclusiveArch, то он не должен быть > noarch. Как минимум, если он не собирается на всех основных архитектурах > сборочницы. Не то, чтобы я был против, но есть недесктопная (как мне сказали когда-то) архитектура ppc64le, и есть некоторые приложения с большим noarch, котрые вряд ли нужны не на десктопе. Как с этими приложениями нужно будет поступать? Без noarch место не жалко? В упомянутом bug 38916 проблема в наличии зависимости на такой пакет, как я понимаю? Вот этот случай, может, надо обрабатывать. В качестве примера OpenCPN (в списке тут есть), который на ppc64le не собирался (-msse2 добавлялся), и вряд ли это чинили в апстриме с тех пор, разве что случайно. Хотя сам ремонт может и не очень сложен. 210102 11 asheplyakov 2022-04-26 15:17:25 +0300 > Если у пакета есть ExcludeArch или ExclusiveArch, то он не должен быть noarch. Это почему же? Вот есть, например, iPXE. Поскольку в Linux бинарники iPXE никогда не выполняются, то для хоста это просто файлы с данными (как, например, firmware). В результате можно легко превратить (armv8) одноплатник в сервер сетевой загрузки для x86 компьютеров. Или наоборот - использовать x86 компьютер для сетевой загрузки armv8 (одноплатников и не только). У нас iPXE (а точнее ipxe-bootimgs) собирается для x86/bios, x86_64-efi, arm64-efi. Чтобы не усложнять, собирается на x86, а для arm64 сборки используется кросс-компилятор. А иначе пришлось бы пришлось бы поддерживать {aarch64,x86}-targeted кросс-компиляторы для всех архитектур (бессмысленная трата времени + источник багов). 235161 12 ruslandh 2023-10-18 23:08:09 +0300 А можно научить сборочницу, чтобы она ориентировалась на архитектуру основного пакета? Т.е. если основной пакет %name, для примера имеет ExclusiveArch: %ix86 x86_64 %arm а вспомогательные пакеты типа %name-date и т.п. и в них прописано BuildArch: noarch то весь пакет собирать в архитектурах %ix86 x86_64 %arm и оставить все проверки для noarch пакетов, но сранивать только результаты сборки в этих архитектурах. А то теряется большая часть смысла в noarch архитектуре. И к тому-же если имеем 10 поддерживаемых архитектурах, - вероятность что пакет собрался во всех десяти поддерживаемых репозиториях архитектурах мала (ну или меньше, чем их бы было три или четыре). - надо сразу переписывать по резульатам сборки спеки, заменяяя все noaarch подпакеты, на указанные в основном пакете архитектуры - теряем проверки noarch архитектуры