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

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

Кроме очевидного набора пакетов, связанных с поддержкой видеокарт и самых свежих драйверов (OpenGL и Vulkan), к примеру, отдельно можно поставлять: ROCm (и аналог от Intel) и набор ПО "геймера" (corectrl, MangoHUD, goverlay, vkBasalt и подобные).
Всё это, как правило, требуется свежайших версий и долгое тестирование с отбрасыванием версии при малейших регрессиях нередко приносит пользователю больше неудобств, чем пользы.
В том же ROCm по сей день немало ошибок и затянутости ввода поддержки новых серий видеокарт (до полугода), а если ещё ждать тестирования со стороны команды ALT, которое, скажем прямо, весьма неторопливое для подобного типа пакетов и при этом будет зарубать версию за версией из-за найденных регрессий, то это приведёт к тому, что ROCm не получится использовать, можно сказать, вообще, а вместе с ним ещё массу программ, которые регулярно подтягивают функционал upstream и вскоре перестают работать на старых версиях ROCm.
Подобное применимо и для новейших игр (в основном работающих через Proton-Wine), которые для работы требуют поддержки свежайших версий Vulkan.

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

Отличие вашего предложения от https://www.altlinux.org/Autoports в том, что вы говорите о системообразующих пакетах, которые требуют достаточно серьёзных изменений (взаимосвязанного обновления сотен пакетов), поскольку одно будет обязательно цепляться за другое. Хорошо, что есть аналогичные решения для Ubuntu. Но как можно заметить, это стороннее частное решение без участия Canonical.
Поэтому интересно, какие усилия вы готовы прикладывать к этому решению? И какой смысл с этим заморачиваться, если можно просто перейти на Сизиф.

Перечисленные пакеты не требуют особых зависимостей, что демонстрирует их поставка через упомянутый PPA.
Через PPA поставляется множество программ, причём даже такие сложные как qemu-kvm вместе со всей "типичной" обвязкой. Если такое возможно даже на Ubuntu, то в ALT, на мой взгляд, тем более не возникнет особых затруднений в связи с более гибким развитием стабильных выпусков. Более того, уже существующие "карманы" являются очень близким аналогом, что определённо упрощает реализацию.

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

Использование Сизифа сопряжено со слишком высокими рисками потери работоспособности, что делает неприемлемым его использование в рабочих задачах. А перебор "удачных" срезов — это совсем не то, на что есть время в процессе выполнения задач организации, и такое решение будет приводить к необходимости формирования собственного отдела тестирования, что далеко не профиль для подавляющего числа организаций даже в нашей нише, не говоря о значительных издержках на содержание таковых специалистов.
Разумеется, можно использовать Docker, но это в очередной раз подпадание под зависимость от третьих лиц вне РФ, а поддержка собственных образов требует инфраструктуры и специалистов.

Исходя из описанного, аналог PPA-репозиториев со свежайшими версиями пакетов под конкретный набор задач является крайне необходимым. Этот механизм позволяет намного более гибко решать задачи бизнеса, а в ряде случаев вовсе получить саму возможность работать, следовательно, определяет выбор дистрибутива для оснащения организации. Так же изощрённым вариантом может быть набор Docker-образов (или иных контейнеров) на базе ALT и специализированный инструментарий, нацеленный на максимальное упрощение решения задач, которые закрывают PPA.
В связи с ростом числа пользователей и от того всё более расширяющимся кругом решаемых с помощью ОС задач, подобные решения становятся экзистенциальной необходимостью. Со стороны ALT это будет сильным конкурентным преимуществом, углубляющим одно из ключевых его достоинств — самодостаточность (сам является платформой) и мощную инфраструктуру.

Ещё один вариант. Организовать упрощённое использования заданий по ряду пакетов. К примеру, через модуль Альтератора сделать автоматическое подключение свежайших заданий для конкретных пакетов (комплектов пакетов), выбранных пользователем. К примеру, галки для полного комплекта по wine, mesa, rocm, firmware-linux и т.п.
По появлению нового задания отключать старое и подключать новое.

Тем самым не придётся организовывать отдельные карманы и выделять дополнительные ресурсы на сопровождение

Created attachment 15154 [details]
скрин inxi -G

При запуске live дистрибутива alt k workstation p10 столкнулся с дикими тормозами. Проблема оказалась в том, что для рендеринга был выбран llvmpipe-драйвер.

Попробовал alt k workstation p10.2. В этой ревизии, хоть драйвер выбирается такой же, производительность уже значительно лучше.

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

Из spec файла из mesa.src.rpm (http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/branch/x86_64/SRPMS.classic/Mesa-23.1.8-alt2.src.rpm) я пришел к выводу, что сборка уже по идее должна идти с llvm 15, но почему-то по факту собранные библиотеки слинкованы с llvm 11.

Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой?

P.S. моя видеокарта: radeon rx 7900 xtx

(Ответ для Vladimir Perepechin на комментарий #5)
> Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой?

Конечно, стоит. Mesa не мой пакет, и я вряд ли именно за него возьмусь, а майнтайнер, ответственный за Mesa, этот баг не читает.

По поводу собственно бага - прошу прощения, год назад руки не доходили, уже даже успел забыть. Теперь появились новые ресурсы, сервис cronbuild переехал на новую более мощную ноду, так что буду думать и потихонечку разрабатывать поддержку.
Есть надежда, что в 2024 желаемый сервис появится.
Будет называться cronpockets? и будет обслуживать произвольное количество микро-addon репозиториев (pockets) по типу cronports, но с фиксированным списком пакетов.

(Ответ для viy на комментарий #7)
> Есть надежда, что в 2024 желаемый сервис появится.
> Будет называться cronpockets? 
cronbackports?

(Ответ для viy на комментарий #6)
> (Ответ для Vladimir Perepechin на комментарий #5)
> > Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой?
> 
> Конечно, стоит. Mesa не мой пакет, и я вряд ли именно за него возьмусь, а
> майнтайнер, ответственный за Mesa, этот баг не читает.

Конкретно этот отчёт о "теоретизировании", что есть потребность в ветке со свежайшими пакетами для поддержки новейшего графического оборудования именно для использования совместно со стабильной платформой (причём такое использование явно обозначать как "на свой страх и риск" для экономии на тестировании). Тем самым все прочие обсуждения тут лишние.

Спасибо. Завел баг https://bugzilla.altlinux.org/48698