Если у пакета есть ExcludeArch или ExclusiveArch, то он не должен быть noarch. Как минимум, если он не собирается на всех основных архитектурах сборочницы. В таком случае следует сборку задания завершать с ошибкой с соответствующим сообщением. Иначе пакет появляется даже на тех архитектурах, сборку на которых явно выключили. См. также: https://bugzilla.altlinux.org/show_bug.cgi?id=38916#c3
Я думаю, эту проверку надо сделать в rpm-build.
(Ответ для 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 Возможно будет достаточно превратить эти предупреждения в ошибки.
Идею поддерживаю, но вообще очень интересен список потенциально пострадавших пакетов. Простой grep по спекам показывает, что таких может быть немало -- хотя как совсем правильно грепать неясно. Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их сборку кроссом? Мне бы для mipsel пригодилось =)
(In reply to Ivan A. Melnikov from comment #3) > очень интересен список потенциально пострадавших > пакетов. Простой grep по спекам показывает, что таких может быть немало -- > хотя как совсем правильно грепать неясно. > > Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их > сборку кроссом? Мне бы для mipsel пригодилось =) +100500 Это PreReq к началу обусждения.
Грубая оценка: $ 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. С какими ещё пакетами из этого списка могут быть проблемы?
(Ответ для 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:) в плане их наличия на целевых платформах (но это только в сборочнице).
Кто-то грозился переделать cross-gcc по-правильному. Как он появится, можно и эту багу решать. Я на ExclusiveArch для edk2 и т.п. не от хорошей жизни перешел.
(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.
Лет шесть назад было аналогичное обсуждение у Федоры: https://pagure.io/packaging-committee/issue/355 которое вылилось в некую встречу, по результату которой формализовали вот что: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies
(In reply to Aleksei Nikiforov from comment #0) > Если у пакета есть ExcludeArch или ExclusiveArch, то он не должен быть > noarch. Как минимум, если он не собирается на всех основных архитектурах > сборочницы. Не то, чтобы я был против, но есть недесктопная (как мне сказали когда-то) архитектура ppc64le, и есть некоторые приложения с большим noarch, котрые вряд ли нужны не на десктопе. Как с этими приложениями нужно будет поступать? Без noarch место не жалко? В упомянутом bug 38916 проблема в наличии зависимости на такой пакет, как я понимаю? Вот этот случай, может, надо обрабатывать. В качестве примера OpenCPN (в списке тут есть), который на ppc64le не собирался (-msse2 добавлялся), и вряд ли это чинили в апстриме с тех пор, разве что случайно. Хотя сам ремонт может и не очень сложен.
> Если у пакета есть 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 кросс-компиляторы для всех архитектур (бессмысленная трата времени + источник багов).
А можно научить сборочницу, чтобы она ориентировалась на архитектуру основного пакета? Т.е. если основной пакет %name, для примера имеет ExclusiveArch: %ix86 x86_64 %arm а вспомогательные пакеты типа %name-date и т.п. и в них прописано BuildArch: noarch то весь пакет собирать в архитектурах %ix86 x86_64 %arm и оставить все проверки для noarch пакетов, но сранивать только результаты сборки в этих архитектурах. А то теряется большая часть смысла в noarch архитектуре. И к тому-же если имеем 10 поддерживаемых архитектурах, - вероятность что пакет собрался во всех десяти поддерживаемых репозиториях архитектурах мала (ну или меньше, чем их бы было три или четыре). - надо сразу переписывать по резульатам сборки спеки, заменяяя все noaarch подпакеты, на указанные в основном пакете архитектуры - теряем проверки noarch архитектуры
