Как это у нас часто бывает, релиз Fedora 32 откладывается из-за найденных ошибок. Качество для нас крайне важно, поэтому мы лучше перенесем выпуск, но исправим найденное при тестировании. А пока мы уже начали собирать фичи следующей Fedora 33. Пока приняли следующие:

• Binutils обновляется с версии 2.33 до 2.34.
• Образы Fedora Cloud будут обновляться каждый месяц.
• ELN, или Enterprise Linux Next. Очень интересное изменение, о нем расскажем чуть ниже.
• Обновление MinGW.
• Улучшения для сборки glibc32. Это пакет, нужный для сборки 32- и 31-битных приложений на 64-битных системах, чтобы обойти ограничения Koji.
• Пакеты будут собираться с Link-time Optimization по умолчанию.
• Обновление Make с версии 4.2 до 4.3.
• Модули будут доступны при сборке RPM.
• OpenLDAP будет поставляться с BerkleyDB и HDB, собранными как динамические библиотеки. Мы постепенно отказываемся от BerkleyDB, и это еще один шаг.
• Обновление Python с версии 3.8 до версии 3.9 и удаление пакетов с Python 2.6 и Python 3.4.
• RPM 4.16.0 и перевод RPM с BerkleyDB на SQLite.
• Отказ от поддержки TLS 1.0 и TLS 1.1 и ряда слабых криптоалгоритмов. Они будут доступны в OpenSSL, если кому-то будет надо, но по умолчанию их использовать не получится.
• Компиляторы CC и C++ будут выбираемы. В будущем можно будет задействовать LLVM/Clang, например.
• При обновлении сервисы будут перезапускаться в самом конце обновления. Вместо скриптлета, будет декларативное указание в сервисе systemd. Еще один шаг к декларативному подходу к управлению сервисами, вместо устаревшего процедурного, когда мы указывали не что нам надо делать, а как надо.

Так вот, про ELN. Это изменение позволит тестировать сборку пакетов в будущем RHEL. Все началось из-за слухов, что в RHEL9 в качестве x86_64 будет подразумеваться процессор с очень современным набором команд. В Fedora, в качестве базового x86_64-процессора сейчас используют старинный AMD K8 из 2003 года, в который, как говорят, игры загружались с магнитофонных кассет.

Типичный программист работает на компьютере с процессором AMD K8.

Если в RHEL потребуют использовать более современный процессор, то любой x86_64 уже не подойдет, да и не всякое ПО соберется. Сначала предложили не дожидаясь RHEL повысить требоваия - отказались, так как даже в Intel не все процессоры подойдут, которые сейчас выпускаются. Затем предложили добавить еще одну архитектуру сборки - процессор-то, получается, не x86_64, как мы считаем. Отказались и от этого в пользу более общего решения. Теперь в рамках этой цели сборки (наподобие f32, f31, rawhide, epel7 и т.д.) можно будет вести разработку в рамках будущего RHEL. Это будет как бы Rawhide, но в нем можно будет тестировать небольшие изменения (оптимизации, команды процессора).