>по моему мнению, как раз здесь sqlite более чем уместен. Если посмотреть
>в код, авторы много SQL-ных фишек используют, отсутствующих в bdb1.85 из
>libc : join-ы, выборки с регэкспами, distinct-ы, сортировки и т.д.Это все было бы прекрасно, если б привело к упрощению и ускорению
разработки, но пока этого не видно. Я начал писать NIH в ноябре прошлого года
и уже, в общем то, давно закончил. Код стабилен, и он работает уже сегодня,
и будет работать и дальше, никуда не денется.
pkgng же пока то ли в альфе то ли в бете.
pkgsrc-ый pkgin начал разрабатываться на год, кажется, раньше, а то и больше,
но nih уже давно предоставляет больше функций. Это не самопиар,
я говорю о выборе подходящего инструмента для данной конкретной задачи.
> Или Вы считаете, что этот функционал нужно обязательно заново создавать?
Нет, я считаю, что данный функционал просто не нужен, ни в каком виде.
Кстати, почитай ман nih на предмет возможностей поиска.
Нет там никакого sqlite, не нужен он там.
Для остального -- тем более.
>solaris тоже вовсю использует sqlite для хранения внутренних баз
Да ради бога, было бы это релевантно. "Модно" -- меня не убеждает.
>> База -- на С, обертка -- на шеле. По-моему так правильнее.
> Да, так правильнее, если наблюдение NIH-а в черном окошке терминала
> является основным и главным рекомендуемым способом обновления софта.
Построение update plan для установки порядка 800 (восьмисот!!!) пакетов
с нуля на атоме-330 занимает порядка минуты. Да, это много, но вполне приемлимо
для запуска один раз за всю жизнь на "десктопе". Типичные же "тормоза"
на серверах или при апдейтах не превышают пяти секунд.
Встанет РЕАЛЬНАЯ проблема в этом месте,
перепишется один(один!) скрипт на С, но пока я проблемы здесь не вижу.
> Но как только к консольной програмке захочется приделать графическую
> или веб морду, вариант с большой С-библиотекой, умеющей все функции
> и маленькими фронтэндами к ней, вызывающими эти функции и представляющими
> их на устройство вывода в удобоваримой форме предпочтительнее.
Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
и гуй к нему лепится на счет раз. Библиотеки здесь ни при чем.
>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> В freebsd этим традиционно занимались portupgrade и portmaster. Думаю,
> нужно ждать когда в них сделают полноценную поддержку pkgng а не просто
> заменят pkg_* на pkg *. В самом pkgng в этом направлении явно еще и
> конь не валялся.
Вот именно, "нужно ждать" и "еще конь не валялся". О чем я и говорю.
