Комитет FESCo (Fedora Engineering Steering Committee), отвечающий за техническую часть разработки дистрибутива Fedora, утвердил предложение по реализации проекта ELN (Enterprise Linux Next), нацеленного на предоставление окружения, основанного на репозитории Fedora Rawhide, которое может применяться для тестирования функциональности будущих выпусков дистрибутива RHEL (Red Hat Enterprise Linux). Для ELN будет подготовлен новый buildroot и процесс сборки для эмуляции формирования Red Hat Enterprise Linux на базе пакетов с исходными текстами из репозитория Fedora. Проект намечен к реализации в рамках цикла разработки Fedora 33...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52731
Это очень позитивная новость для всех, кто пользуется 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 в рамках пакета.
что только люди не придумают, лишь бы не использовать Debian
Дебиан давно уже использовали...если ты понимаешь о чем я.
Debian и nix :)
А я прочитал. Спасибо за хороший комментарий.
Спасибо за толковый коммент.Стоит отметить что ELN - сам по себе не решит проблему совместимости пакетов. ELN - это инфраструктурная вещь, которая позволит приложить EL-конфиг к Fedora Rawhide и посмотреть насколько не совпало и что сломалось. Это скорее такой инструмент для анализа и оповещения разработчиков, чем решение проблемы.
Однако это лишь часть того что происходит сейчас в экосистеме Fedora и CentOS. И если скомбинировать ELN как систему раннего оповещения и инициативу CentOS Stream как место где разработка RHEL будет вестись в открытом виде _до_ релиза RHEL, то действительно получится то, что ты описываешь.
В целом RHEL перестает быть скрытным и выходит в открытый доступ на всех уровнях, не только публикацией исходников после релиза, но самой разработкой. И тем кто строит какие-то решения на базе RHEL/CentOS теперь будет проще и быстрее с ним работать.
Просто в этом уже нет прибыли
ну что это такое
давайте уже в арчь!
Arch самостоятельный, а Fedora - собственный полигон для тестирования (что данные изменения в который раз подтверждают).
arch самостоятельный полигон для тестирования новшеств, на базе которых формируются сборки fedora. А fedora собственный полигон тестирования для rhel. Так правильней.
Fedora, вообще-то, в первую очередь полигон тестирования для... Fedora. Которая прекрасно может существовать и без RHEL, если, внезапно, связь с Red Hat оборвётся, а команда разрабов сохранится в составе, позволяющем делать дистрибутив уровня выше васяновского.
Ух...хватит уже так шутить, боюсь живот надорвать %-)
Весь не интерпрайз это полигон для тестирования на хомячках.
Писали бы лучше ебылды.
А как же Nih-синдром?
Gentoo Linux:
Первый выпуск: 31 марта 2002 годаRPM:
First commit: Nov 27th 1995
Вы видели тот рпм? А деб? Ебилды крутые и удобные. Действительно, практически все поставленные "цели" решаемы в рамках генты с минимумом затрат. А оставшиеся, излишне сомнительны, чтобы о них думать.
Поддерживаю. У Генты самые удобные инструменты.
Даже единственный нормальный линукс Chrome OS. Поддерживает ебилды.
Видел и rpm specs, и правила сборки dep-пакетов, и ebuild'ы. Из всей тройки rpm specs самый удобные.
> Видел и rpm specs, и правила сборки dep-пакетов, и ebuild'ы. Из всей
> тройки rpm specs самый удобные.Можно менять параметры сборки ебилда просто задав переменную в текстовом файле или переопределив хуки. Патчи применяются сами собой, достаточно положить их рядом. Крайне удобно для всяческих экспериментов. Всё происходит в песочинице, у конкурентов с этим вроде какие-то проблемы были.
Красота на самом деле https://projects.gentoo.org/pms/7/pms.html
В Makefile тоже так можно это не рокетсайн
> В Makefile тоже так можно это не рокетсайнМейкфайлы это уже исходники. Прелесть именно в том, чтобы ничего с ними не делать. И менять параметры пакета одним словом, в максимально простом и незатратном формате.
> Можно менять параметры сборки ебилда просто задав переменную в текстовом файле или переопределив хукиКак и в RPM.
> Патчи применяются сами собой, достаточно положить их рядом.
Как и в RPM.
> Всё происходит в песочинице,
Как и в RPM.
Да ну что ты мне рассказываешь, перед тем как свалить на генту я тоже регулярно собирал эти rpm.
Ну, если не утруждать себя чтением мануалов, то любой инструмент будет максимально враждебным.
Тока в генте для применения патча не надо править ебилд а в рпм надо править спек ага
> Тока в генте для применения патча не надо править ебилдНе знаю-не знаю. Вот свежий пример: и патч добавили, и ебилд поправили: https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/...
> в спеках парпметры гуляют
А теперь то же самое, но по-русски.
Речь про пользовательские патчи, не прописанные в ебилде.
Ты их просто кладешь куда надо, portage сам их наложит, ничего править не надо
Ага ну и да в спеках парпметры гуляют так что..
И что как это относится к тому что мы не будем никогда использовать чужие подделки, а будет делать свои? Даже если чужие поделки во всем лучше.
> чужие поделки во всем лучше"Proudly found elsewhere!"
Детального обоснования лучшести мы, разумеется, не дождемся.
> А как же Nih-синдром?А как же NIX-синдром?
>на предоставление окружения, основанного на репозитории Fedora Rawhide, которое может применяться для тестирования функциональности будущих выпусков дистрибутива RHEL (Red Hat Enterprise Linux).Ясно, понятно. Так и записал: "Федора - это тестовый полигон".
Как бы да, но в то же время Rawhide это тестовый полигон Федоры. Странно, что все возбуждаются на то, что его используют как тестовый полигон. :)
странно , что об этом узнали только сейчас. скольтко помню федора была полигоном красной шапки. она создавалась для этого и самое смешное никто этого не скрывал и не скрывает. странно то , что другие не знают. я помнится возился с федорой которая была тогда еще fedora core 6. и тогда прямым текстом было сказано , что это полигон редхата. и все согласились с этим. ну как бы выпуск федоры каждые пол года как раз и подразумевал именно это.
Кто-то возится с "тестовым полигоном", другие силятся пристроиться поближе то ли к важняку Столлману, то ли к его лобковым вшам, третьи ещё в чем-то своём упражняются...Никак не пойму, какая в этом может быть сверхсмертельная проблема? )
Первая мысль после прочтения заголовка: а ещё Проект по эмуляции VisualStudio на базе Emacs
А если наоборот?
Ну есть же для товарищей с особенными потребностями Vim-режим для Sublime Text. Значит и Emacs-режим для VSCode кто-то может учинить.
> А если наоборот?Как там дела сейчас обстоят не знаю, но для VS 2010 оно было и вполне работало:
https://devblogs.microsoft.com/visualstudio/emacs-emulation-.../
> ELN также позволит проверять намеченные изменения условных блоков в spec-файлах, т.е. собирать пакет со срабатыванием условий с переменной "%{rhel}", установленной в значение "9" (переменная "%{fedora}" ELN будет возвращать "false"), симулируя сборку для будущей ветки RHEL.Это не переменные, макросы.
Похоже на костыль
Python
готовят переход всех, включая винду, на RHEL. МежДелМаш бабки на ветер не бросает
Эти люди никогда не слышали о Debian -е? Я принашу вам благую весть! Есть такой дистрибутив по-имени Debian!
разочарую. сейчас дебиан не сильно отличается от убунты. разве что своим вечным "устареванием" версий программ. но во всем остальном почти такой же. так что хоть дебиан , хоть убунта, хоть федора. различий минимум.да системд внесла единообразие в линуксы однако.
>различий минимум.да системд
> внесла единообразие в линуксы однако.Стали одинаково глючными и не прозрачными?