>[оверквотинг удален]
>>>> базам данных.
>>> при эксплуатации rpm-alt мне что-то не помню, бывали ли когда нужны db?.?-utils...
>> Если хотите разобраться с, например, проблемами производительности
>> или повреждением БД в процессе эксплуатации, нужно быть специалистом
>> по низкоуровневым БД.
> Понятно, что при выборе между удобством таких разборок и производительностью/надёжностью
> в 99,(9)% остальных случаев стоит учитывать и первое. Вот только
> ставить его во главу угла -- ну модно, конечно. Но
> не работает. Дальше по этой дорожке -- соседняя новость с
> post-meritocracy.Мода здесь не при чем. Это просто разумная достаточность. Ресурсы любого человека и/или компании ограничены, если есть возможность их потратить на копания в кишках BDB или на написание или исправление полезного функционала в rpm, то для всех полезнее их потратить на последнее. В вопросе производительности достаточно помнить о ней, думать о ней, поддерживать ее на _достаточном_ уровне и не перегибать палку. Иначе, по такой логике, можно предложить писать %pre, %build и %install в спеках на си, чтобы было быстро, со строгой типизацией, надежно и не было входа "шелл-макакам".
>[оверквотинг удален]
>> типовые проблемы с БД, корневая причина которых, на мой взгляд,
>> именно в том, что на пакетный менеджер возложены совсем не
>> свойственные ему задачи, которые он выполняет плохо.
> Пробежался по этим вот из попавшихся на первой странице именно гугла:
> http://forum.altlinux.org/index.php?topic=28293.0
> http://forum.altlinux.org/index.php?topic=9405.0
> http://forum.altlinux.org/index.php?topic=42874.0
> http://forum.altlinux.org/index.php?topic=34644.0
> http://lists.altlinux.org/pipermail/devel/2002-April/086943....
> -- удивлён Вашим предположением даже в его краткой форме.
Не понял, что Вы хотели сказать этими ссылками? База поломалась, для ее починки требуется ручное вмешательство, то, что повезло и база починилась, а данные не потерялись, - это хорошо, но это не оправдывает то, что RPM допустил поломку БД. Ломом - это когда с помощью rm, dd или иным целенаправленным вмешательством ломают базу, а когда внезапно отключается электричество - это типовая ситуация, которую БД обязана уметь разруливать и поддерживать свою консистентность настолько, насколько это возможно и позволяет окружающая обстановка (файловая система, железо и пр.). На ум пришло такое сравнение: в браузерах Chromium и Firefox применяется Sqlite, не припомню проблем с ними (в Хромиуме как-то профиль немного повреждался, но вряд ли из-за БД), хотя все мы используем браузеры гораздо больше, чем RPM. Из этого можно сделать вывод, что есть примеры, когда консистентность БД поддерживается лучше, чем в rpm+bdb (возможно, сравнение не уместное, не знаю).
>> Все аргументы против этого, которые слышал, сводились к теоретической
>> потенциальной потери производительности. Ну пускай какие-то операции
>> выполняются чуть дольше
> Это сразу же стукнет и по сборочнице, если что.
Разумно, если кто-нибудь сравнивал в Федоре, будет интересно почитать.
>> на тех машинах, где запускается rpm, это не будет заметно,
>> на embeded его не запускают.
> Вообще-то запускают.
Кто запускает, тот пусть и поддерживает соответствующие бекенды в rpm, а 99% пользователей и разработчиков не должны страдать и тратить время впустую из-за 1% потребителей со специфическими задачами. Иначе напоминает "соседнюю новость с post-meritocracy" ;)
>>> неспециалисты по разработке вроде Panu останутся неспециалистами
>> А какие претензии к Panu?
> Порой неспособен понять хороший патч, но это полбеды.
> Он способен _выкинуть_ хороший патч. На этом фоне наступание на давно
> известные грабли -- лишь вторые полбеды.
> Более подробно писал в новости про rpm 4.14, если не ошибаюсь.
Почитаю комментарии там. Пока могу сказать, что в последние годы под руководством Panu rpm4 улучшился настолько, что сейчас можно заменить rpm5 на rpm4 без значимых регрессий в функционале. Если посмотреть на rpm в не такой уж и старой centos 7, то в нем нет, например, файловых триггеров. Дикостью кажется. На такое rpm5 вряд ли заменили бы. Да, бывают ошибки, в т.ч. весьма глупые и у Panu, их приходится править (https://github.com/rpm-software-management/rpm/commit/bea87e), но в целом со стороны проект выглядит как активно развивающийся в правильную сторону, адекватный, открытый и без больших перегибов (особенно с учетом непростого наследия, доставшегося со времен Джеффа).
