Формат RPM и сопутствующая инфраструктура управления пакетами, хотя и в целом серьезно опережает конкурентов, в частностях от них же порой и отстает. Плюс внедрение новых технологий требует изменений в существующем процессе работы. Наши участники понимают это, и работа уже ведется - Software Collections, DNF на замену Yum, новая сборочная система copr, - это лишь видимая часть, и не все из текущих проектов доживут до стадии внедрения в Fedora.

Наша текущая проблема в том, что несмотря на стандартизированность RPM и развитость инфраструктуры по управлению пакетами, разработчики устанавливают и используют приложения, собранные их исходников, причем чаще, чем стоило бы. Дело в в т.ч. и в том, что прежде, чем пакетами управлять, надо их откуда-то взять. Создание пакетов, простая пересборка установленных, это область, где мы сильно проигрываем конкурирующим решениям, например Portage (это, кстати, было причиной, почему Portage был выбран инструментом для управления пакетами в CoreOS). К сожалению, нашим инструментам, особенно для работы с инфраструкрурой проекта, все еще не хватает интеграции друг с другом.

Инженер Red Hat, Jan Zelený, предложил план улучшения инфраструктуры по управлению пакетами в Fedora/RHEL на ближайшую пятилетку. Jan разделил пользователей RPM на три группы - существующие пользователи, у которых ничего не должно в результате изменений поломаться, разработчики, постоянно ставящие что-то из исходников, в обход RPM, и devops/админы, использующие Chef/Puppet для синхронизации машин, и не использующих RPM. Ну и как всегда, у любого сколь нибудь развитого языка программирования есть свой способ собирать дополнения для этого языка, ничего не знающий о пакетах. Отдельно он отмечает неготовость для десктопа существующих графических интерфейсов, хотя благодаря работе Richard Hughes процесс идет. Сейчас Jan предлагает следующий план исправления сложившейся ситуации:

• Ближайший год / в процессе.
• • Дельты метаданных для Yum/DNF вместо постоянного выкачивания десятков мегабайт загзипованных XML.
  • Переход на Python3 в DNF.
  • Новый бинарный формат для RPM. Пока, любые попытки написать свою реализацию парсера пакета сопровождаются зубовным скрежетом и криками "быдлокод".
  • Интерфейс для написания плугинов для RPM.
• 1-2 года.
• • Стабилизация DNF и замена им Yum.
  • Улучшенная поддержка SELinux.
  • Сложные "вычисляемые" зависимости. Это совершенно новая фича. Суть в том, что зависимости будут не только "зашитые", но и вычисляемые в момент установки/удаления других пакетов. Они будут записываться в базу данных Yum и будут переопределять существующие, либо добавляться к ним. Короче говоря, это второе появление "Recommends", вычисляемых, а не записываемых на этапе сборки.
  • Новый бинарный формат для RPMDB. Он должен быть расширяем, причем с заделом на будущее. Например, NoSQL-база для JSON-записей?
  • Новая база для yumdb. На самом деле, пока сложно сказать, что будет в ней, а что в RPMDB, но уже ясно, что ее тоже придется изменять и расширять.
  • Дальнейшее упрощение формата spec-файлов.
  • Обработка пакетов, удаленных из репозиториев.
• 2-5 лет. Высокий приоритет.
• • Управление репозиториями из командной строки. Хочется сделать так же просто, как и подключение PPA в Ubuntu. Опять-же, RPM/Yum/DNF должен не перекачивать метаданные в случае переименования репозитория, как это сейчас происходит.
  • rpmbuild должен выходить с ошибкой в случае не-UTF8 spec-файлов. Выкиньте уже ваши KOI8-R файлы, пожалуйста.
  • Быстрое создание RPM-файла (cabal2spec, gem2spec, и т.п. + подсказки по BuildRequires + больше автогенераторов Requires).
  • Быстрое создание Software Collections. Например для Python или Ruby другой версии.
• 2-5 лет. Средний приоритет.
• • Улучшение журналирования операций (перенос из Yum в rpm).
  • Уменьшение количества блокирующих операций.
  • Интеграция с облачными системами, такими, как OpenShift.
  • Автоматическое подключение внешних RPM-баз. Например, вы подключаете NFS-раздел, и RPM находит установленные там пакеты и управляет ими (например, перевычисляет вычислимые зависимости).
• 2-5 лет. Низкий приоритет.
• • Потокобезопасность RPM. Не смейтесь, пожалуйста, нам самим грустно. Сейчас мы просто не позволяем запускать вторую копию Yum/DNF в параллель - очень удобный и простой фикс для достижения threadsafe.
  • Интеграция с состоянием демонов. Не только перезапуск, но и перезапуск по какому-то системному событию (обновление других демонов, например).
  • Улучшение верификации. Например, не только сообщение об изменении файла, но и diff изменения, если речь идет об изменении файлов конфигураций.
  • Автообновление конфигурационных файлов. Сейчас, т.к. изменения не вычисляются, то если администратор изменил конфиг, установленный в пакете, а обновленный пакет содержит обновленный-же конфиг, то останется старый файл, а новый будет установлен рядом, как *.rpmnew. Хотелось бы применить изменения к новому и установить его.
• Далекое светлое будущее. Низкий приоритет.
• • Полностью модульный RPM, создающий пакеты не только из SPEC-файлов, и на выходе выдающий не только RPM-пакеты.

Мы очень надеемся, что участники коммьюнити вокруг других дистрибутивов присоединятся к проектированию будущей системы установки и управления пакетами - Jan полностью открыт для обсуждения. Пишите ему, и давайте все вместе сделаем RPM лучше!