The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Проект по эмуляции сборки Red Hat Enterprise Linux на базе Fedora

14.04.2020 12:48

Комитет 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.

ELN предоставит инфраструктуру, позволяющую собирать Fedora-пакеты с использованием методов, применяемых в CentOS и RHEL, и даст возможность сопровождающим пакеты Fedora на ранней стадии отлавливать изменения, которые могут потенциально отразиться на разработке RHEL. ELN также позволит проверять намеченные изменения условных блоков в spec-файлах, т.е. собирать пакет со срабатыванием условий с переменной "%{rhel}", установленной в значение "9" (переменная "%{fedora}" ELN будет возвращать "false"), симулируя сборку для будущей ветки RHEL.

Конечной целью является пересборка репозитория Fedora Rawhide так, как если бы он был RHEL. В ELN планируется пересобирать только небольшую часть из коллекции пакетов Fedora, востребованную в CentOS Stream и RHEL. Успешные пересборки ELN планируется синхронизировать со внутренними сборками RHEL, добавляя в пакеты дополнительные изменения, которые недопустимы в Fedora (например, добавление торговых марок). При этом разработчики будут стараться минимизировать отличия между ELN и RHEL Next, разделяя их на уровне условных блоков в spec-файлах.

Другим важным применением ELN будет возможность экспериментировать с воплощением новых идей, не затрагивая основные сборки Fedora. В частности, ELN будет полезен для создания сборок Fedora, отражающих прекращение поддержки старого оборудования и задействование по умолчанию дополнительных расширений CPU. Например, параллельно можно будет сформировать вариант Fedora, определив в требованиях к CPU обязательную поддержку инструкций AVX2, после чего протестировать влияние производительности от применения AVX2 в пакетах и принять решение о реализации изменения в основном дистрибутиве Fedora. Подобные тесты актуальны для проверки пакетов Fedora в условиях изменения требований к аппаратным архитектурам, намеченным в будущей значительной ветке RHEL, без блокирования штатного процесса сборки пакетов и подготовки релизов Fedora.

  1. Главная ссылка к новости (https://lists.fedoraproject.or...)
  2. OpenNews: Дистрибутив Fedora 32 перешёл на стадию бета-тестирования
  3. OpenNews: Fedora планирует перевести RPM с BerkeleyDB на SQLite
  4. OpenNews: Первый стабильный выпуск Fedora CoreOS
  5. OpenNews: Red Hat представил CentOS 8 и непрерывно обновляемую редакцию CentOS Stream
  6. OpenNews: Fedora и CentOS запускают Git Forge. GitLab открывает 18 проприетарных возможностей
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/52731-fedora
Ключевые слова: fedora, redhat, rhel, build
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.16, Аноним (16), 16:18, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Это очень позитивная новость для всех, кто пользуется 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 в рамках пакета.

     
     
  • 2.18, DeaDBeeF (ok), 16:22, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    что только люди не придумают, лишь бы не использовать Debian
     
     
  • 3.36, псевдонимус (?), 20:14, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Дебиан давно уже использовали...если ты понимаешь о чем я.
     
  • 3.44, Коровавирус (?), 01:25, 15/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Debian и nix :)
     
  • 2.34, Аноним (34), 19:36, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А я прочитал. Спасибо за хороший комментарий.
     
  • 2.37, А (??), 20:50, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Спасибо за толковый коммент.

    Стоит отметить что ELN - сам по себе не решит проблему совместимости пакетов. ELN - это инфраструктурная вещь, которая позволит приложить EL-конфиг к Fedora Rawhide и посмотреть насколько не совпало и что сломалось. Это скорее такой инструмент для анализа и оповещения разработчиков, чем решение проблемы.

    Однако это лишь часть того что происходит сейчас в экосистеме Fedora и CentOS. И если скомбинировать ELN как систему раннего оповещения и инициативу CentOS Stream как место где разработка RHEL будет вестись в открытом виде _до_ релиза RHEL, то действительно получится то, что ты описываешь.

    В целом RHEL перестает быть скрытным и выходит в открытый доступ на всех уровнях, не только публикацией исходников после релиза, но самой разработкой. И тем кто строит какие-то решения на базе RHEL/CentOS теперь будет проще и быстрее с ним работать.

     
     
  • 3.38, microsoft (?), 21:52, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто в этом уже нет прибыли
     

  • 1.1, Аноним (1), 13:16, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ну что это такое
    давайте уже в арчь!
     
     
  • 2.2, anonymous (??), 13:27, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Arch самостоятельный, а Fedora - собственный полигон для тестирования (что данные изменения в который раз подтверждают).
     
     
  • 3.4, анонимус (??), 13:34, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    arch самостоятельный полигон для тестирования новшеств, на базе которых формируются сборки fedora. А fedora собственный полигон тестирования для rhel. Так правильней.
     
     
  • 4.28, IRASoldier_registered (ok), 17:28, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Fedora, вообще-то, в первую очередь полигон тестирования для... Fedora. Которая прекрасно может существовать и без RHEL, если, внезапно, связь с Red Hat оборвётся, а команда разрабов сохранится в составе, позволяющем делать дистрибутив уровня выше васяновского.
     
  • 3.5, псевдонимус (?), 13:35, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ух...хватит уже так шутить, боюсь живот надорвать %-)
     
  • 3.6, Аноним (6), 14:02, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Весь не интерпрайз это полигон для тестирования на хомячках.  
     

  • 1.3, Аноним (3), 13:32, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Писали бы лучше ебылды.
     
     
  • 2.7, Аноним (6), 14:03, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А как же Nih-синдром?
     
     
  • 3.8, Аноним (8), 14:28, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Gentoo Linux:
        Первый выпуск: 31 марта 2002 года

    RPM:
        First commit: Nov 27th 1995

     
     
  • 4.11, Аноним (11), 14:54, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы видели тот рпм? А деб? Ебилды крутые и удобные. Действительно, практически все поставленные "цели" решаемы в рамках генты с минимумом затрат. А оставшиеся, излишне сомнительны, чтобы о них думать.
     
     
  • 5.12, Аноним (12), 15:06, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поддерживаю. У Генты самые удобные инструменты.
     
     
  • 6.13, Аноним (6), 15:22, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Даже единственный нормальный линукс Chrome OS. Поддерживает ебилды.
     
  • 5.19, Аноним (19), 16:32, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Видел и rpm specs, и правила сборки dep-пакетов, и ebuild'ы. Из всей тройки rpm specs самый удобные.
     
     
  • 6.21, Аноним (11), 16:44, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Видел и rpm specs, и правила сборки dep-пакетов, и ebuild'ы. Из всей
    > тройки rpm specs самый удобные.

    Можно менять параметры сборки ебилда просто задав переменную в текстовом файле или переопределив хуки. Патчи применяются сами собой, достаточно положить их рядом. Крайне удобно для всяческих экспериментов. Всё происходит в песочинице, у конкурентов с этим вроде какие-то проблемы были.

    Красота на самом деле https://projects.gentoo.org/pms/7/pms.html

     
     
  • 7.22, GentooBoy (ok), 16:56, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В Makefile тоже так можно это не рокетсайн
     
     
  • 8.24, Аноним (11), 17:07, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мейкфайлы это уже исходники Прелесть именно в том, чтобы ничего с ними не делат... текст свёрнут, показать
     
  • 7.23, Аноним (8), 16:58, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно менять параметры сборки ебилда просто задав переменную в текстовом файле или переопределив хуки

    Как и в RPM.

    > Патчи применяются сами собой, достаточно положить их рядом.

    Как и в RPM.

    > Всё происходит в песочинице,

    Как и в RPM.

     
     
  • 8.25, Аноним (11), 17:08, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну что ты мне рассказываешь, перед тем как свалить на генту я тоже регулярно ... текст свёрнут, показать
     
     
  • 9.27, Аноним (8), 17:21, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну, если не утруждать себя чтением мануалов, то любой инструмент будет максималь... текст свёрнут, показать
     
  • 8.39, microsoft (?), 21:55, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тока в генте для применения патча не надо править ебилд а в рпм надо править спе... текст свёрнут, показать
     
     
  • 9.41, Аноним (8), 22:26, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не знаю-не знаю Вот свежий пример и патч добавили, и ебилд поправили https ... текст свёрнут, показать
     
     
  • 10.46, аНоним (?), 14:12, 15/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Речь про пользовательские патчи, не прописанные в ебилде Ты их просто кладешь к... текст свёрнут, показать
     
  • 8.40, microsoft (?), 21:56, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ага ну и да в спеках парпметры гуляют так что ... текст свёрнут, показать
     
  • 4.14, Аноним (6), 15:23, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И что как это относится к тому что мы не будем никогда использовать чужие подделки, а будет делать свои? Даже если чужие поделки во всем лучше.
     
     
  • 5.15, Аноним (8), 15:33, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > чужие поделки во всем лучше

    "Proudly found elsewhere!"

    Детального обоснования лучшести мы, разумеется, не дождемся.

     
  • 3.35, Аноним (35), 19:36, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А как же Nih-синдром?

    А как же NIX-синдром?

     

  • 1.9, Аноним (9), 14:37, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >на предоставление окружения, основанного на репозитории Fedora Rawhide, которое может применяться для тестирования функциональности будущих выпусков дистрибутива RHEL (Red Hat Enterprise Linux).

    Ясно, понятно. Так и записал: "Федора - это тестовый полигон".

     
     
  • 2.10, КО (?), 14:50, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как бы да, но в то же время Rawhide это тестовый полигон Федоры. Странно, что все возбуждаются на то, что его используют как тестовый полигон. :)
     
     
  • 3.42, анонимуслинус (?), 23:25, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    странно , что об этом узнали только сейчас. скольтко помню федора была полигоном красной шапки. она создавалась для этого и самое смешное никто этого не скрывал и не скрывает. странно то , что другие не знают. я помнится возился с федорой которая была тогда еще fedora core 6. и тогда прямым текстом было сказано , что это полигон редхата. и все согласились с этим. ну как бы выпуск федоры каждые пол года как раз и подразумевал именно это.
     
  • 2.43, 0x0 (?), 01:13, 15/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-то возится с "тестовым полигоном", другие силятся пристроиться поближе то ли к важняку Столлману, то ли к его лобковым вшам, третьи ещё в чем-то своём упражняются...

    Никак не пойму, какая в этом может быть сверхсмертельная проблема? )

     

  • 1.17, Аноним (17), 16:19, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Первая мысль после прочтения заголовка: а ещё Проект по эмуляции VisualStudio на базе Emacs
     
     
  • 2.26, Аноним (26), 17:15, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если наоборот?
     
     
  • 3.29, IRASoldier_registered (ok), 17:30, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну есть же для товарищей с особенными потребностями Vim-режим для Sublime Text. Значит и Emacs-режим для VSCode кто-то может учинить.
     
  • 3.50, Аноним84701 (ok), 12:15, 16/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А если наоборот?

    Как там дела сейчас обстоят не знаю, но для VS 2010 оно было и вполне работало:
    https://devblogs.microsoft.com/visualstudio/emacs-emulation-extension-now-avai

     

  • 1.20, Аноним (19), 16:33, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > ELN также позволит проверять намеченные изменения условных блоков в spec-файлах, т.е. собирать пакет со срабатыванием условий с переменной "%{rhel}", установленной в значение "9" (переменная "%{fedora}" ELN будет возвращать "false"), симулируя сборку для будущей ветки RHEL.

    Это не переменные, макросы.

     
  • 1.30, Аноним (30), 17:42, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Похоже на костыль
     
     
  • 2.33, Ni (??), 18:38, 14/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Python
     

  • 1.31, Аноним (31), 17:54, 14/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    готовят переход всех, включая винду, на RHEL. МежДелМаш бабки на ветер не бросает
     
  • 1.45, Аноним (45), 07:21, 15/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Эти люди никогда не слышали о Debian -е? Я принашу вам благую весть! Есть такой дистрибутив по-имени Debian!
     
     
  • 2.48, анонимуслинус (?), 19:16, 15/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    разочарую. сейчас дебиан не сильно отличается от убунты. разве что своим вечным "устареванием" версий программ. но во всем остальном почти такой же. так что хоть дебиан , хоть убунта, хоть федора. различий минимум.да системд внесла единообразие в линуксы однако.
     
     
  • 3.49, псевдонимус (?), 05:46, 16/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >различий минимум.да системд
    > внесла единообразие в линуксы однако.

    Стали одинаково глючными и не прозрачными?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру