Запилил утилитку: check-link-consistency for ArchLinux

Ничего не понятно, но очень интересно. А какой юзкейс у программы?

Binary distros need such tool much more than source-based. It's like static vs dynamic typing in programming languages: source-based distro checks package's dependencies when program builds, binary — when it runs. Funny that I've hit this problem in less than a week after switching from Gentoo to Artix.

Никогда не сталкивался с таким - обычно при установке менеджер говорит "пакету А нужны пакеты B и С, установлю и их тоже", при удалении - "пакет B нужен для пакета A, либо удаляем все вместе, либо все оставляем" и "пакеты B и C нужны были только для пакета A, и так как A ты удалил - можем заодно и эти два удалить". Что нужно сделать чтоб получить проблему с этим? Или это фича только пакетного менеджера арча?

Есть дополнительные (рекомендуемые, optdepends) зависимости, которые не ставятся по-умолчанию.

Не понял для чего это тулза, зачем мне знать для чего та тулза для генту, а рунглиш в репе в описании не осилил.

Я так понял, она ищет исполняемые файлы и библиотеки, у которых отсутствуют обязательные зависимости (not found в ldd). Но это крайне необычная ситуация для бинарного дистрибутива, где список зависимостей обычно формируется автоматически при сборке. Либо в Arch зависимости прописываются исключительно руками в PKGBUILD, либо конкретно этот дериватив что-то мутит.

Нет на арче так же, единственное опционные (дополнительный функционал программ не влияющий на их основную работу, например youtube-dl для mpv) зависимости не ставятся по умолчанию, надо указать их установку. Однако при установке пакета они предлагаются для установки (с кратким описанием) есть в информации о пакете, и при их удалении сообщается каким пакетам в системе они нужны.

Не гентушник так что тоже не понял для чего программка

Ничего не понятно, но очень интересно. А какой юзкейс у программы?

А я всегда говорил, что source-based vs binary -- это как статическая vs динамическая типизация.

А в этом каменте я выкатил идею. Обработку опциональных зависимостей сделал, символы в процессе.

В universe-репу ArtixLinux утилита добавлена сегодня ночью: pacman -Si check-link-consistency.

А я всегда говорил, что source-based vs binary – это как статическая vs динамическая типизация.

Смелое и некорректное обобщение. Убогий (или неправильно используемый?) сборочный фреймворк в арче не является всеобщей проблемой.

Есть подозрение, что под «не-убогим» и «правильно используемым» сборочным фреймворком понимается дебиан, у которого весь софт – говно мамонта. А в rolling release со свежайшим софтом накладки неизбежны: невозможно пересобирать всю пакетную базу ежедневно.

Я правильно понимаю, что такая ситуация может возникнуть лишь при частичном обновлении, которые официально в Арче не поддерживаются? Частичные обновления — это когда ты обновляешь не всю систему через pacman -Syu, а отдельные пакеты или группы через pacman -Sy <package> ...?

https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

Никаких частичных обновлений, эти инструкции я читал. См ссылку на форум artix из ссылки на мой прошлый пост (с телефона пишу, влом копипастить), там проблема висела несколько дней, и была не в частичных обновлениях. Также с месяц назад, когда я уже гонял тулзу локально, в течении 1-2 недель какая-то либа из libreoffice ссылалась на что-то типа libpoppler-…117 когда на системе стояла …115 (или наоборот), но поскольку офис вроде как работал, я никаких действий не предпринимал. Ещё в моей репе в /src/etc в sample-конфиге нескольким пакетам добавлены опциональные зависимости, про которые мейнтейнеры забыли.

Там на вашем атрексе свои репы что ли? Ситуация типичная для частичных обновлений, бывает конечно что мантейнер провтыкает зависимость, за десять лет пользования арчем один раз встречался лично и пару раз на форуме видел сообщения. Но для этого есть багтрекер и исправляют в течении пары дней

Тогда это, должно быть, полезная программа. Однако на Арче лично я, за много лет его использования, с таким ни разу не сталкивался, оттого и непонимание её предназначения. По идее, наверное, мейнтейнеры должны проверять все зависимые пакеты и пересобирать их в случае несоответствия версий либ. Вообще, не знаю как там у них всё устроено, не интересовался. В Артиксе, вероятно, ресурс ограничен, ввиду меньшей популярности дистра, и такие накладки бывают чаще.

Заморочился ты, конечно, аж полноценную прогу написал. Респект. А почему пакмановскую libalpm не использовал? Там, мне кажется, должны быть полезные тебе функции.

Тогда это, должно быть, полезная программа.

Ну в AUR-то клон гентушной revdep-rebuild лежит. Хотя он бесполезен чуть менее чем полностью, о чём сам честно предупреждает: если needed-либа не найдена, то может это ашипка, а может и опциональная зависимость. Я эту неоднозначность убрал. Ну и ускорил в 550 раз, гы.

А почему пакмановскую libalpm не использовал?

Да чёт не подумал. Я ужас как гордился что заюзал libelf и libarchive вместо fork+exec ldd+nm+unzstd, а с libalpm теперь уж поздно, т.к. категорически влом. Мне б добить символы (там ад кромешный, задрало уже в конец эксперименты ставить) и пошло оно всё в жопу.

Кроме того, не факт, что она умеет что мне надо, а именно: (1) скачка без установки опциональных зависимостей: pacman -Sw --noconfirm {длинный список}; (2) получить по имени зависимости имя пакета и файла архива. Второй пункт может и умеет, а полноценную обработку в п.1 уже гораздо более вряд ли.

libelf вместо ldd

Насколько я знаю, ldd ищет зависимости рекурсивно, то есть, если для какой-то из прилинкованных либ нужна другая либа, то он такое показывает, в отличие от objdump.

Твой код я особо не смотрел :)

А ещё бывают же либы, которые грузятся через dlopen, што с ними делать?

Мне б добить символы

Ну, это уже на полноценный линкер тянет xD

Насколько я знаю, ldd ищет зависимости рекурсивно

Да. А я собираю по файловой системе все динамические ELF и каждый анализирую независимо от остальных; и ошибка вылетит при анализе не приложения, а конкретно той либы, чья непосредственная зависимость отсутствует. Что есть гуд: не «какая-то либа у данной программы битая», а «такая-то конкретно либа из такого-то пакета битая» – и не важно, линкует ли её кто-то явно, грузит через dlopen() или не использует вообще.

А ещё бывают же либы, которые грузятся через dlopen, што с ними делать?

Это уже написал выше, и кстати это ерунда по сравнению с тем, что на системе огромное количество ELF-ов с локальными символами, которые на самом деле нифига не локальные, а импортируются либами, подгружаемыми через dlopen как плагины. Например, /usr/lib/Xorg (который вообще не либа, строго говоря; file его определяет как executable) экспортирует кучу символов которые импортируются x11-драйверами. (А некоторые импортируемые драйверами символы не экспортирует никто вообще. Щас я примерно представляю, куда смотреть, чтобы понять как такое чудо возможно, но вернусь туда в лучшем случае через неделю.) Где-то 12% всех символов – такие вот «локальные», но в DYNSYM фигурирующие. И если включить их в поиск-резолвинг, то придётся в конфиг в дополнение к десятку директив addLibPath впилить сотню директив addLib, потратив массу времени, чтобы найти какие либы какие символы экспортируют:

addLib /usr/lib/xorg/modules/** /usr/lib/Xorg
addLib /usr/lib/perl5/5.34/site_perl/** /usr/lib/perl5/5.34/core_perl/CORE/libperl.so
addLib /usr/lib/perl5/5.34/vendor_perl/** /usr/lib/perl5/5.34/core_perl/CORE/libperl.so
# И ещё под сотню строк.

Так что, очевидно, я пойду по принципу «лучше хоть что-то чем ничего вообще» и локальные символы буду игнорить; даже для гентушника-задрота это перебор.

И это не единственная проблема; есть ещё две столь же гиморных, одну из них условно говоря понял как захачить сразу же после того, как психанул и залил на гитхаб версию без символов.

Ну, это уже на полноценный линкер тянет xD

Изо всех сил стараюсь избежать настолько глубокого изучения, но весь мой предыдущий жизненный опыт показывает, что тем всё и закончится. Никогда на костылях не получалось до финиша доезжать. Ну авось, всё ж когда-то происходит впервые.

Подозрение верное :) Но, во-первых, не древнее, чем в Gentoo, а gcc/binutils и прочее такое бывают новее, чем в Arch. Во-вторых, если не ошибаюсь, в RPM с этим (зависимостями) тоже всё окей.

Но, во-первых, не древнее, чем в Gentoo, а gcc/binutils и прочее такое бывают новее, чем в Arch.

«Хорошие шутки» – так называлась программа Шаца, Лазаревой и Пушного.

https://packages.debian.org/bookworm/binutils

https://archlinux.org/packages/core/x86_64/binutils/

https://packages.debian.org/bookworm/gcc

https://archlinux.org/packages/core/x86_64/gcc/

Ок, по двум пакетам

gcc/binutils и прочее такое бывают новее, чем в Arch.

убедил. Осталась мелочь – весь остальной софт, который

не древнее, чем в Gentoo

=)

Gentoo, в отличие от двух других, я не использовал, ориентировался в основном на утверждения местных гентушников. Но вот, например: https://repology.org, рейтинг «By number of projects with up to date packages».

Что-то у меня люди-кони в голове смешались. Посмотрел щас readelf-ом – ни в /usr/lib/Xorg, ни в /usr/lib/perl5/5.34/core_perl/CORE/libperl.so символы не локальные. Директивы addLib нужны для резолвинга символов в либах, подгружаемых как плагины, чтобы ткнуть их носом в ту либу, которая их собственно подгружает и чьи символы они импортируют; это ортогонально symbol visibility & binding. Но что в системе локальных символов было 12% – помню.

Rolling release по определению не может содержать более древний софт, чем стабильный версионируемый дистр. Подозреваю, что даже gcc/binutils с твоей стороны был каким-нибудь читерством: либо дебиан только что релизнулся, либо ты привёл версии из ещё не релизнувшейся нестабильной ветки (собственно, второе).

собираю по файловой системе все динамические ELF и каждый анализирую независимо от остальных

Ого, ну это круто. Радикально, я бы сказал.

локальные символы буду игнорить; даже для гентушника-задрота это перебор

Да нафига ты вообще с этими символами связался? Сравнивать по циферкам версий либ, на мой взгляд, вполне достаточно. А то так можно и до анализа исходников дойти.

Но автору виднее, конечно. Могу лишь посочувствовать :) и пожелать успехов.

Ну авось, всё ж когда-то происходит впервые.

Если такая деятельность приносит успокоение и никому не вредит, то я буду голосовать за продолжение :)

психанул и залил на гитхаб версию без символов

приносит успокоение

https://youtu.be/hwvRdxbz1Ro?t=53

Это как ldd + пакетный менеджер? Ну полезно, если выкачивать что-то, чего нет в репах, но там возникает проблема конфликта версий библиотек, ускорить процесс разрешения тупиковой ситуации может, но я привык руками, тем более, что в дебиане есть очень много по

«такая-то конкретно либа из такого-то пакета битая» – и не важно, линкует ли её кто-то явно, грузит через dlopen() или не использует вообще

Про dlopen() точно не погорячились?

?

А вот и свеженькое подвезли:

# check-link-consistency 2>&1 | ts -s %.T
00:00:00.000009 INFO  Analyzing installed packages...
00:00:00.074292 INFO  Scanning filesystem for bins & libs...
00:00:00.311455 INFO  Resolving libs...
00:00:00.315075 INFO  Downloading optional dependencies of problematic packages...
00:00:09.359853 INFO  Analyzing optional dependencies of problematic packages...
00:00:11.082080 INFO  Resolving libs...
00:00:11.082225 ERR   ------------------   -----------------   ----------------------
00:00:11.082252 ERR   Package              Problematic File    Unresolved Needed Libs
00:00:11.082268 ERR   ------------------   -----------------   ----------------------
00:00:11.082284 ERR   audacity 1:2.4.1-7   /usr/bin/audacity   libSoundTouch.so.1    
00:00:11.082298 ERR   ---------------------------------------------------------------
00:00:11.082311 ERR   Total 1 problematic file(s): 1 in 1 package(s) + 0 unassigned.
00:00:11.082323 ERR   ---------------------------------------------------------------

На системе стоит libSoundTouch.so.2. Репортить-нет?.. Нет: влом, и пофиг в общем-то на этот audacity; а мейнтейнеры теперь и сами могут эту тулзу запустить если кто зарепортит.

Ну это не арч, пинайте местных ментейнеров или репу смените.

 yay -Fx libSoundTouch
extra/soundtouch 2.3.1-1 [установлен]
    usr/lib/libSoundTouch.so
    usr/lib/libSoundTouch.so.2
    usr/lib/libSoundTouch.so.2.3.1

yay -Qii soundtouch |grep Требуется
Требуется            : audacity  gst-plugins-bad

ldd /usr/bin/audacity |grep SoundTouch
	libSoundTouch.so.2 => /usr/lib/libSoundTouch.so.2 (0x00007fd2bb753000)

Ну это не арч

Ежу понятно. Выше уже каментили про проблемы производных дистров с меньшим людским ресурсом. В любом случае, я себя с этой стороны обезопасил, так что независимо от того, осилю я символы или нет, переход с генты на артикс можно считать завершённым.

Так название темы и тег смените тогда

Не сменю. Оно работает с pacman, так что пригодно и для работы в самом арче. В т.ч. вполне годится в качестве замены AUR-овскому findbrokenpkgs.