>> чтобы избавить разработку и эксплуатацию пакетного менеджера
>> от необходимости быть специалистом по низкоуровневым
>> базам данных.
> при эксплуатации rpm-alt мне что-то не помню, бывали ли когда нужны db?.?-utils...Если хотите разобраться с, например, проблемами производительности или повреждением БД в процессе эксплуатации, нужно быть специалистом по низкоуровневым БД. Если в процессе работы пакетного менеджера возникают нюансы с БД, то встает вопрос, как их отлаживать. Например, у нас была ситуация, когда rpm5 не записывал один из провайдов установленного пакета в /var/lib/rpm/Provides. Когда сам rpm управляет транзакциями и делает прочую низкоуровневую работу, чтобы такое отлаживать, нужно быть специалистом по низкоуровневым БД. Когда такая работа заменяется формированием строки SQL-запроса для sqlite, становится хотя бы понятно, с чего начать отладку. Также можно захотеть вручную покопаться в БД в обход rpm, в случае с BDB это сделать совсем нетривиально.
Если скажете, что не сталкивались с проблемами с работой БД rpm в rpm-alt, то не поверю, в p8 после работы apt-get регулярно в фоне зависала или по очень долгу весела какая-то операция с БД, кстати, как решили это? В p9+ не замечал такого. По запросу "rpm rebuild db site:altlinux.org" также нагугливаются типовые проблемы с БД, корневая причина которых, на мой взгляд, именно в том, что на пакетный менеджер возложены совсем не свойственные ему задачи, которые он выполняет плохо.
>> Правильное решение -- переход на с BerkleyDB на Sqlite
> С большой вероятностью как раз неправильное, но об этом лучше в той
> новости.
Все аргументы против этого, которые слышал, сводились к теоретической потенциальной потери производительности. Ну пускай какие-то операции выполняются чуть дольше, на тех машинах, где запускается rpm, это не будет заметно, на embeded его не запускают. Чем еще неправильно?
> Боюсь, будет "за всё хорошее против всего плохого" -- неспециалисты по разработке
> вроде Panu останутся неспециалистами
А какие претензии к Panu?
