>> Ну, если вы доверяете команде Manjaro, то легко доверитесь и этим парням: https://aur.chaotic.cx/
>> И любым другим: https://wiki.archlinux.org/title/unofficial_user_repositories

Не доверюсь ибо уровень доверие к ним абсолютно разный конкретно для меня...

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

Т.э. таки получается что это с Arch больше проблем с сборкой из-за того что не успевают актуализировать? В Manjaro эти пакеты появятся чуть позже и таких проблем обычно нет.

>> Добавим, что некоторые библиотеки (особенно крестовые, не будем показывать на Qt пальцем) имеют проблемы со стабилизацией API даже между минорными релизами. Результат немного предсказуем: софт не собирается, уже собранный выдает всеми любимый "undefined reference to symbol". Остаётся только в каждом отдельном случае патчить и сутками стучаться головой в апстрим.

Вот это и есть тот ключевой момент о котором я писал "Проблемы могут быть если разработчик или сопровождающий плохо работает с зависимостями".
Смотри норм разработчик если видит что ломается совместимость в новых версиях зависимости, то не просто меняет кусок кода, а оставляет совместимым и с более старыми версиями насколько это возможно. Для конкретно qt обычно используют конструкции вида `#if QT_VERSION` и такой код норм собирается как на новых так и на старых версиях.
Далее давай рассмотрим ситуацию когда наоборот версии поддерживаемые ПО старее тех которые используют пользователи Arch-based дистрибутивов, допустим из-за того что разработчик пользуется условной убунтой где пакеты более старые. Тогда сопровождающий после того как заметил проблему со сборкой должен либо написать разработчику либо отправить PR и подождать пока эти исправления будут добавленны. Если разработчик никак не реагирует на все это (что бывает не часто), то по возможности делает патчи сам и применяет их перед сборкой. Также сопровождающий может применять конкретный патч в зависимости от условий (например если версия qt попадает в диапазон версий для которых актуален этот патч). Также для самых крайних случаев когда сопровождающий не может создать такой патч, то он может просто в зависимостях указать нужные версии и пакет не будет даже начинать собираться пока все зависимости не будут удовлетворены. Это намного лучше кучи ошибок при сборке и пользователю сразу понятно что не так. Опытные пользователи при этом могут отредактировать сценарий сборки и сделать нужные патчи что б собрать даже в таком случае, а неопытные просто подождут.

>>Но, наверное, гуру теоретики знает какую-то магию "хорошей работы с зависимостями" и сейчас спасёт мир от нас, никчемных практиков, одной серебрянной пулей в голову?

Спасибо, за незаслуженное клеймо, но методы описанные выше были проверены на практике в качестве сопровождающего и они действительно работают...