ubuntu угрожают своим пользователям стать rolling releases

редкие пакеты (плагины к gimp, clang) и их в роллинге не было

Их же легко добавить туда.

одиночная просьба в багзилле ничего не меняет в долгой перспективе.

Так ты про вообще отсутствие пакетов или именно про tumbleweed?

Тогда скажем так: большинство не выставляет tumbleweed в целях сборки

Пока у него не будет официального статуса, мало что поменяется (и так людей не хватает для покрытия тестированием всего что есть, хотя практически во всех дистрибутивах всё гораздо хуже с тестированием). Я и сам скептически отношусь к tumbleweed, считаю что лучше использовать стабильную систему + отрельные репозитории, например KDE:Release:**, LibreOffice:Stable и аналогичные.

парочка из них апдейтит системные библиотеки

Это ключевое.

У меня собственно была ситуация, когда из-за версии gtk и ещё чего-то не запускались anjuta, erik4, erik5.

На счёт гнома не знаю, с KDE такого быть не должно.

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

редкие пакеты (плагины к gimp, clang) и их в роллинге не было

Их же легко добавить туда.

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

В качестве типичного примера ошибки при сборке нужных мне библиотек могу назвать ошибку в ассемблере: buildservice почему-то жаловался на отсутствующую инструкцию (которая есть в x86 и действительно отсутствует в x64). Сборка производилась под x86, но всё равно жаловался! Причём не для всех целей, а для 3 из 4 выбранных версий opensuse.

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

Пока у него не будет официального статуса, мало что поменяется (и так людей не хватает для покрытия тестированием всего что есть, хотя практически во всех дистрибутивах всё гораздо хуже с тестированием)

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

Да, апдейт системных библиотек - ключевой источник проблем. Но что поделать, если даже автор deadbeef патчил кодеки? То есть он-то их статически прилинковывает, т.е. патчи на остальной системе не скажутся - но в debian и opensuse очень сильно недолюбливают статическую сборку.

программы и библиотеки потому и отсутствуют, что собираются не ахти как

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

В качестве типичного примера ошибки при сборке нужных мне библиотек могу назвать ошибку в ассемблере

Разработчикам SUSE сообщал? В отличие от других rpm-дистрибутивов в SUSE используется не только rpmlint, и автоматические проверки строже, чем в той же Fedora. Хотя надо смотреть что именно было.

при автоматической пересборке некоторые пакеты, которые раньше работали без проблем

Для Factory - обновления библиотек, мне о таком постоянно напоминания сыплются (но это из-за того, что у меня доступ к ~400-м пакетам).

если пакеты меняются каждый день

А главное разработчики часто толком и не пишут что поменяли.

Но что поделать, если даже автор deadbeef патчил кодеки?

Объяснить что неправ и патчи надо отправлять в соответствующие библиотеки.

То есть он-то их статически прилинковывает, т.е. патчи на остальной системе не скажутся - но в debian и opensuse очень сильно недолюбливают статическую сборку.

Ну не так уж и сильно, если это действительно надо то допускается. Хотя при первой возможности рекомендуется уходить от использования этого.