Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Планы по RPM/Yum/DNF на ближайшую пятилетку

Это архивная статья

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

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 лучше!

Комментарии