DocAlpkgtool научился, наконец, с зависимостями работать?Мне тут из зала подсказывают что нет, в последнем релизе 10.2 так и не научили.

Знаете, есть такое простое и понятное приспособление для сверления, называется коловорот. Розетка ему не нужна, аккумуляторов тоже нет, работай сколько влезет. Но почему-то специалисты, которым нужно сверлить стены, занимающиеся монтажом используют не простые и понятные коловороты, а сложные и непонятные электродрели, перфораторы, шуруповёрты. UVV-mail , вы не знаете, почему?

В такой альтернативе, FreeBSD 6.1-RELEASE.
Вообще же, для чего система-то нужна?

v6y
Ну а вдруг на самом деле все не так плохо? :) Ау, слакваристы :)

Всё ровно настолько плохо.
v6y
авторугу, делать мне больше нечего, как запоминать зависимости пакетов

Все один лишь только раз :) Зато приобретешь дополнитльные знания о тех или иных ньюансах ;-).
, тем более что в новых версиях они могут измениться.

И как часто такое случается?

Эти сакральные знания я получу коммандой pkg_info -r package_name во FreeBSD, rpm -q -R package_name в rpm-based Linux. Для apt я сейчас уже команду не вспомню, давно не юзал, но и там я не буду лопатить сотню README для того, чтобы узнать зависимости сотни пакетов. Внимание, вопрос: мне больше нечего делать? Если я буду запоминать наизусть зависимости десятков, а то и сотен пакетов -- какую характеристику серверов это повысит: стабильность, безопасность, производительность, совместимость?
v6y

авторВ таком случае, можно просто закинуть становку пакета и его зависимостей в какой-нибудь скрипт.
да все можно, только зачем изобретать велосипед?
Написать один раз несколько строк == изобрести велосипед? И опять вернемся к вопросу - как часто обновляются серваки?

А вы полагаете, ваш велосипед будет ездить существенно лучше, чем стандартный и многократно испытанный? Вам оно надо, к документированию действительно нестандартных решений на серверах добавлять ещё и документирование всего стандартного? Или как иначе передавать сервера другому админу? Касательно же регулярности обновления, по мере обнаружения критических уязвимостей.
v6y

авторА разве сборка rpm не включает в себя компиляцию сырцов?
включает, только в spec файле указываются зависимости. Допустим ты собрал пакет. И тебе надо его установить на 20 серверах. Как ты будешь это делать на слаквари
Один раз набросаю соответствующий скрипт, уже говорил :)

Опять же, чем ваш велосипед лучше стандарта?
v6y
И что ты будешь делать если тебе надо пересобрать пакет с другой опцией?

А что будешь делать ты в этом случае? Пересобирать rpm?

Думаю, в этом случае Alex_hha поправит spec-файл и да, пересоберёт rpm. При этом изменения сохранятся в spec-файле, где их найдёт любой админ, знакомый с администрированием rpm-based дистрибутивов. Ваш же велосипед относительно предсказуемо найдёте только вы, и либо вы выполняете лишнюю работу по документированию того, что может документироваться само, либо подходите к администрированию безответственно, не документируя важные и из самой системы адекватно не определяемые настройки.
v6y

авторчто-нибудь пропатченное или установленное из сырцов (апач, пхп, постгря, мускл)
ради интереса попробуй обновить apache+php+mysql, когда они установлены из исходников.

Немного проясни, что значит обновить в данном контексте? До новой версии или наложить патч, закрывающий некую уязвимость?

Т.к. в практике бывает нужно и то, и другое, то оба варианта.
v6y
автор
2 v6y
сколько вам надо аргументов привести?

И давно мы на "вы"? :) Ну пока ты привел только один - плохой менеджер пакетов. Давай еще парочку и я сразу сдамся (а пока предлагаю ничью ) Для меня отстутсвие менеджера пакетов пока небольшое неудобство и не более того :)

Связанные с "плохостью менеджера" неудобства аудита и сопровождения сервера парочкой аргументов не считаются?

v6y[quot ALex_hha]
Наверное ПАТАМУШТА время админов, умеющих своими руками построить систему безвозратно ушло

Удачи.
Нет, просто время админов стоит денег. И время простоя production сервера стоит больших денег.