При сборке resource-agents получаем: x86_64: NEW unmet dependencies detected: ldirectord#4.14.0-alt1:sisyphus+345762.100.1.1@1713964559 /usr/bin/rm resource-agents#4.14.0-alt1:sisyphus+345762.100.1.1@1713964559 /usr/bin/bash из-за checking for rm... /usr/bin/rm checking for bash... /usr/bin/bash
Тут по сути главный вопрос, где мы будем переопределять ac_cv_path_RM, ac_cv_path_BASH_SHELL и прочие?
Наверное, CanonPath мог бы заменять requires, но если это не используется в самой конфигурируемой проге.
Используется наверняка. Вообще говоря, не нужно полных путей к rm в скриптах.
/usr/bin/bash используется в shebang, а /usr/bin/rm в данном конкретном случае прилетает в service файл. Там принято писать полный путь.
Я бы сделал export ac_cv_path_RM=/bin/rm export ac_cv_path_BASH_SHELL=/bin/bash в пакете. Вопрос, много ли у нас таких пакетов.
(In reply to Andrew Vasilyev from comment #4) > /usr/bin/bash используется в shebang, а /usr/bin/rm в данном конкретном > случае > прилетает в service файл. Там принято писать полный путь. Отсюда, видимо, следует, что нам в любом случае придётся предусматривать то, что Глеб предложил, с фиксацией ac_cv_path_*. Но далеко не факт, что этого достаточно.
Посмотрел по логам последней тестовой пересборки без filesystem 3: % grep -Er 'checking for rm...[[:space:]]+(/bin/|)rm' success | tail success/samba-4.19.6-alt1:checking for rm... rm success/scponly-4.8-alt2.qa1:checking for rm... /bin/rm success/scponly-4.8-alt2.qa1:checking for rm... /bin/rm success/sdcc-1:4.4.0-alt1:checking for rm... rm -f success/snapper-0.10.7-alt1:checking for rm... /bin/rm success/splint-3.1.2-alt2.qa1:checking for rm... rm success/squid-6.8-alt1:checking for rm... /bin/rm success/vdsm-4.50.6-alt1.1:checking for rm... /bin/rm success/wfc-R2304-alt1:checking for rm... /bin/rm success/whoson-2.05-alt2.1:checking for rm... /bin/rm Не все эти проверки из-под autotools (хотя бы samba можно вспомнить), поэтому они могут игнорировать ac_cv_*. Видно, что проверки принципиально разные: где-то rm, где-то /bin/rm, а где-то вообще `rm -f`.
(In reply to Gleb F-Malinovskiy from comment #5) > Я бы сделал > > export ac_cv_path_RM=/bin/rm > export ac_cv_path_BASH_SHELL=/bin/bash > > в пакете. Вопрос, много ли у нас таких пакетов. % grep -Elr 'checking for rm...[[:space:]]+' ~/success | wc -l 76 % grep -Elr 'checking for rm...[[:space:]]+/bin/rm' ~/success | wc -l 58 % grep -Elr 'checking for rm...[[:space:]]+rm -f' ~/success | wc -l 4 % grep -Elr 'checking for rm...[[:space:]]+[^r/]' ~/success | wc -l 1 Этот один очень забавный: libabigail-1.8.2-alt1:checking for rm... yes
(Ответ для Gleb F-Malinovskiy на комментарий #5) > export ac_cv_path_RM=/bin/rm > export ac_cv_path_BASH_SHELL=/bin/bash Костыль помог, спасибо.
А вот сколько содержат "checking for bash": % grep -a -Elr 'checking for bash[.][.][.][[:space:]]+' ~/success | wc -l 53 % grep -a -Elr 'checking for bash[.][.][.][[:space:]]+/bin/bash' ~/success | wc -l 33 % grep -a -Elr 'checking for bash[.][.][.][[:space:]]+/bin/sh' ~/success | wc -l 15 % grep -a -Elr 'checking for bash[.][.][.][[:space:]]+[^/]' ~/success | wc -l 5 Последние 5 тоже забавные: % grep -a -Er 'checking for bash[.][.][.][[:space:]]+[^/]' success success/armagetronad-0.2.8.3.4-alt1:checking for bash... yes success/armagetronad-0.2.8.3.4-alt1:checking for bash... yes success/gnuastro-0.22-alt1:checking for bash... yes success/libxc-6.2.2-alt1:checking for bash... yes success/swtpm-0.8.1-alt1:checking for bash... yes success/wxedid-0.0.27-alt2:checking for bash... yes Минимум один из них уже не проходит unmet check: https://git.altlinux.org/tasks/346583/ [00:00:09] checking for bash... /usr/bin/bash
В моём списке тех пакетов, которые точно будет нужно пересобрать в p11, нашлось 2 пакета, которых это коснулось: librarian: https://git.altlinux.org/tasks/346583/ [00:00:09] checking for bash... /usr/bin/bash apcupsd: https://git.altlinux.org/tasks/346043/ [00:00:04] checking for sh... /usr/bin/sh
JFYI team:/beehive/logs/Sisyphus/x86_64/latest$ grep -Elr '^Requires:.*/usr/bin/(ba)?sh' success | sort success/apcupsd-3.14.14-alt3 success/autogen-5.18.16-alt1 success/bash-defaults-5.2.15-alt1 success/corosync-3.1.8-alt2 success/corosync-qdevice-3.0.3-alt1 success/gnustep-make-2.8.0-alt2.1 success/lbdb-0.39-alt2 success/librarian-0.8.1-alt7 success/libsmi-0.5.0-alt2 success/mpb-1.5-alt5 success/ngsolve-6.2.2304-alt1 success/pacemaker-2.1.7-alt1 success/pekwm-0.2.1-alt1 success/quilt-0.67-alt2 success/verlihub-0.9.8e-alt3
(In reply to Vitaly Chikunov from comment #12) > JFYI > > team:/beehive/logs/Sisyphus/x86_64/latest$ grep -Elr > '^Requires:.*/usr/bin/(ba)?sh' success | sort > success/apcupsd-3.14.14-alt3 > success/autogen-5.18.16-alt1 > success/bash-defaults-5.2.15-alt1 > success/corosync-3.1.8-alt2 > success/corosync-qdevice-3.0.3-alt1 > success/gnustep-make-2.8.0-alt2.1 > success/lbdb-0.39-alt2 > success/librarian-0.8.1-alt7 > success/libsmi-0.5.0-alt2 > success/mpb-1.5-alt5 > success/ngsolve-6.2.2304-alt1 > success/pacemaker-2.1.7-alt1 > success/pekwm-0.2.1-alt1 > success/quilt-0.67-alt2 > success/verlihub-0.9.8e-alt3 С остальными можно постепенно разобраться.
Ещё в одном месте столкнулись. Какой прогресс по ошибке ?
Мне из переписки непонятно какое решение правильно ? /usr/bin/bash - это корректно ? если нет, то почему ?
Исправить _эту багу_ самым простым для мейнтейнеров способом было бы лучше, переделав такие R: и P: в вид `executable(bash)`, не зависящий от PATH. Другое похожее решение — определить операцию, отображающую такие пути в некий канонический путь. Один из вариантов такой операции я успел описать здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=50527#c2 Были высказаны и другие позиции.
(In reply to Anton Farygin from comment #15) > Мне из переписки непонятно какое решение правильно ? Пока что мейнтейнеры делали так: 1) смотрели, какая из двух зависимостей /bin/x, /usr/bin/x кем-либо предоставляется; 2) ставили в своём пакете тот hashbang (или же путь в ином месте, ...), который — результат п. 1. > /usr/bin/bash - это корректно ? Вот /usr/bin/sh — (пока что) точно неправильно. А про bash могут быть другие варианты. > если нет, то почему ? Согласно comment 16, если в авторитетном перечне из пакета lsb не указан predefined path для некой команды Y, отличный от её realpath-положения в файлодереве, то указывать её как /usr/bin/Y можно.
(In reply to Arseny Maslennikov from comment #16) > Исправить _эту багу_ самым простым для мейнтейнеров способом было бы лучше, > переделав такие R: и P: в вид `executable(bash)`, не зависящий от PATH. Вот для штук типа `rm` этот вид — самый дальновидный и корректный. А bash — это же интерпретатор такой, как питон.
(In reply to Arseny Maslennikov from comment #18) > (In reply to Arseny Maslennikov from comment #16) > > Исправить _эту багу_ самым простым для мейнтейнеров способом было бы лучше, > > переделав такие R: и P: в вид `executable(bash)`, не зависящий от PATH. > > Вот для штук типа `rm` этот вид — самый дальновидный и корректный. А bash — > это же интерпретатор такой, как питон. (Gleb F-Malinovskiy from comment #3) > Вообще говоря, не нужно полных путей к rm в скриптах.
