Долгое время для хранения служебных данных в RPM использовалась BerkleyDB. Это довольно старое ПО, да еще и с неудобной лицензией (AGPL, начиная с версии 6.x). Заменить BDB планировали давно, и даже написали NDB, экспериментальный бэкенд, который и включили в RPM версии 4.13.

Начиная с RPM 4.14, который будет фичей Fedora 27, разработчики планируют переключиться на новый бэкенд. Как всегда бывает, мало кто увидел, что изменение внесено уже пару лет назад, и реальное обсуждение началось лишь сейчас.

Довольно очевидны проблемы - апгрейд будет требовать изменения самой базы данных, вероятно "сломается" некоторое стороннее ПО. Но главное - на GitHub лежит туча встраиваемых KV-хранилищ, транзакционных баз данных, реляционных баз данных, и простых data store. Зачем при таком богатстве выбора создавать что-то новое?

Сразу поступили предложения пересмотреть решение и использовать SQLite или LMDB - самые напрашивающиеся варианты. Это, конечно, далеко не полный список.

По поводу библиотеки SQLite - интересно то, что такой бэкенд в RPM был, но его удалили, мол, был медленный. Скорее всего, дело было в низком качестве самого бэкенда, и в том, что вряд ли кто-то использовал SQL-функциональность библиотеки.

По поводу же LMDB - был только RFE, а не PR. Реального кода никто еще не предложил, хоть заявленные характеристики библиотеки и превосходят ожидания. Однако, мы знаем, что разработчики LMDB (они же разработчики OpenLDAP) - люди уникальные. Наш товарищ, Леонид Юрьев, по неизвестной причине уже который год с коллегами убирается в этих Агиевых конюшнях, для чего, помимо всего, пришлось форкнуть LMDB. Мы желаем им удачи, разумеется, но также нужно признать, что когда он начинает перечислять проблемы в стоковой LMDB, становится понятно, что просто так в RPM это брать нельзя.

Обсуждение только началось, и посмотрим, чем все закончится.