Это очень позитивная новость для всех, кто пользуется CentOS в проде, хотя тем кто не пользуется это не совсем очевидно.Представьте себе задачу, что вам нужно иметь на сервере конкретную версию конкретной софтины, а версия из репозитория вам не подходит. Это типичная ситуация во всех дистрибутивах. Бывает нужно как обновлять, так и понижать версию. В виду того как в RHEL собирают пакеты, там чаще нужно хитро обновлять с переносом патчей. В CentOS/RHEL для многих пакетов версия софта не так важна как версия пакета. Они бекпортируют патчи не только в ядро но много куда ещё, в основном там багфиксы и чтобы встроить свою версию да еще и с новыми багфиксами в систему правильно и чтобы её обновлениями не корёжило и не ломало нужно делать так:
1. Взять SRPM из CentOS и прочитать назначения дополнительных патчей, убедившись, что все эти патчи не актуальны для новой версии
2. Переписать spec под новую версию и подсунуть новый тарбол ИЛИ скачать готовый спек из Fedora под эту же самую версию, если он есть готовый
3. Скачать свежайший SRPM из Fedora и проверить, какие патчи наложила Fedora на апстрим поверх всего, и зачем они. Там всё будет видно на апстримовских issue в самих проектах, которые вы обновляете.
4. Принять решение, будете ли вы переносить патчи из свежайшей федоры под свою версию или оставить только то что есть, параллельно проверив совместимость с патчами CentOS, если для этой версии они всё еще актуальны
5. Сделать rpmbuild и установить пакет, обновив номер сборки.
Для прикладного софта эта процедура у вас не отнимет много времени и всё будет хорошо, но вот если ваш софт поближе к системе, то у вас могут начаться проблемы совместимости между Fedora и CentOS. Самая частая проблема - несовместимость targeted policy SELinux. В Fedora более новая версия, они там поменяли кучу макросов. Я лично на этот случай беру кусок актуальной targeted policy из Fedora и портирую её под CentOS собирая в RPM, который её поставит как дополнительную политику и прописываю этот rpm в зависимости к основному. Есть даже готовый SRPM под это дело, чтобы не париться с написанием, но это уже творческий процесс. Кроме того, может сыграть роль различие версий в зависимостях, или как бывает в CentOS конкретно 8, может не оказаться пачки devel-пакетов, их физически нет в репозиториях, нужно их самим собрать и доустановить из стандартных поставляемых SRPM. И вот в сравнении с самим обновлением и сборкой пакета этот поиск граблей отнимает время.
Enterprise Linux Next на базе Fedora Rawhide удалит эту проблему. Причём это выгодно всем и тем кто пользуется CentOS и сам поддерживает свои дистрибутивы и техподдержке RHEL у которой уменьшится количество рутины и штатным меинтейнерам, которые зачастую одни и те же и для Fedora, и для RHEL и для CentOS в рамках пакета.
