ALT Linux Bugzilla – #38919

Я думаю, эту проверку надо сделать в 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 архитектуры