>> В одном флаконе так сказать.
>> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
>> то есть в 3 раза меньше,
> Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска
> утилит из под сишного кода.Бред сивой кобылы.
> Очевидно писалось наспех.. Как говорится.. нет ничего более постоянного..
Нет.
>> это если не считать совершенно неуместного
>> здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.
> очень даже уместного. При распухании базы хотя бы до пятисот пакетов pkg_install
> начинает заметно тормозить.
Нет. Не начинает.
>> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
> Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу.
Нет. RTFM.
> Тупо не хватает нормальных зависимостей на библиотеки/ориджины. Отсутствие инфы о
> том с какими KNOB-ами собран пакет.
С чем собран пает? Какой инфы не хватает?
> Приходилось костылить. Собсно portupgrade - попытка вылечить
> зубы через опу(и ему это даже удается). остальные менеджеры еще менее
> удачны.
portupgrade к pkgsrc отношения не имеет. Иди читай документацию.
>> Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
> Если и так всё переделывать, то какая разница.
Не нужно ничего переделывать, и pkgin и nih написаны поверх pkgsrc-ного pkg_install.
> При нормальной архитектуре затраты
> на написание на Си менеджера-обертки примерно одинаковые по сравнению с шеллом.
> Если не меньше.
Нет.
>> Нет. Сборку я вообще не трогаю, это отдельная песня.
>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> Нет смысла. т.к. pkg_* нужно было выкинуть целиком.
Если фришники развели бардак, пусть выкидывают и переделывают.
