>Хм, ну не знаю, как по мне так очень даже и ничего.
>Пакетом можно будет сконфигурировать машину в любое время... Смотря что делать через пакеты.
>>Кстати, пакеты в Debian это еще одна ужасная(имхо) тема: apt отличная, мощная,
>>потрясающая вещь, но deb-пакеты, точнее, их костыльная сборка, это, имхо, ужас
>>:(
Вы rpm когда-нибудь собирали? Патчи в спеке прописывали? Макросами пользовались? Уверены, что знаете возможности альтернативы, что бы сравнивать?
>Но, пакеты в debian собраны пожалуй наиболее правильно, аккуратно и удобно для
>конечного пользователя.
Совсем не уверена. Любой дистрибутив считает, что собран (и собирается) наиболее аккуратно и удобно для конечного пользователя, например, вспомним Arch: совсем не похож ни на Debian, ни на RH, но пользуется заслуженной популярностью среди своих юзеров.
Секрет в том, что дистрибутив, обычно, ориентируется на определенную группу юзеров.
В частности, rpm удобен именно тем, что конечный пользователь (тот же администратор) может запросто собрать и пересобрать пакет с помощью rpmbuild, исправив спек.
Порог вхождения в мантайнеры очень низкий, в сравнении с изучением autotools, make и своих систем костылей со скриптами для сборки.
Кроме того, что rpm (не yum apt'у) в чем-то уступает deb для пользователя я так же не согласна: что есть в deb, например, вместо rpm -V ? Есть внешняя утилита debsum, которая не дает даже части функционала.
>>Ой, это совсем костыль, имхо. Наверное, через koan в RH тоже как-то
>>можно извратнуться, но имхо, он как и debootstrap нужен для других
>>целей: что бы поставить новую систему сверху имеющейся...
>
>Хм, а почему вы считаете это костылем? Он позволяет быстро и удобно
>собрать систему для OpenVZ контейнера.
Разработчики OpenVZ апстрима для этого написали vzpkg/vzyum/vzrpm, vzpkg2 (точнее, это полумертвый форк, но он поддерживает и deb и apt), по аналогии с платной и проприетарной Virtuozzo, в которой пакетный менеджмент контейнеров огранизован не в пример лучше OVZ :(
Кстати, за идею спасибо :) Я долго не могла придумать, чем заменить vzyum хотя бы для генерации template cache, собственно, debootstrap и mock должны это сделать изящно для Debian/Ubuntu и для RH платформы
>>Не согласна: тогда можно считать, что emacs, например, костыль, и его нужно
>>закопать в пользу vim или вообще ничего не умеющего ee. (/me
>>использует vim)
>
>Ну emacs это просто другой редактор. Тогда давайте не считать скрипты на
>шеле велосипедом по отношению к скриптам Anaconda, шел более распространенный и
>часто применяемый инструмент...
Если Вы смотрели тот код, что я запостила выше (кстати, он явно не образец чистоты), Вы могли заметить, что в нем есть куски на bash'е (я еще и на питоне иногда вставляю).
Просто это то же самое, что вместо SystemV сценариев(кстати, на шелле) и управления ими через update-rc или chkconfig использовать rc.local (давайте его напишем, например, на Perl?)
Просто средство, которое выполняет какую-то функцию, должно ее делать хорошо, что бы не пришлось, в большинстве случаев дописывать.
>>Правда толкать KISS стоит, имхо, не везде и не всегда, и debconf
>>и его концепции я и не собиралась критиковать, он достаточно удобен,
>>а вот d-i с Anaconda и Yast сравнения по функционалу не
>>выдерживает :(
>>
>
>Возможно тут дело вкуса... Мне просто не нравится сама идея Yast и
>др.
Мне тоже. Пожалуй, полное отсуствие врапперов вроде debconf и yast (как в RH) мне нравится больше: любую проблему с любым пакетом можно решить, прочитав апстримную документацию по пакету, не разбираясь, что там имел ввиду мантайнер, хотя те же alternatives, вероятно, больший костыль, чем "мягкие зависимости" вместо configure опций