* Peter V. Saveliev [040108 22:58]: > Сорри за занудство, просто в отсутствие развёнутой документации по пакету, > очень сложно ставить задачи, с ним связанные. Вот, тут прозвучало мнение, > что для моих задач больше подходит sandman. Возможно, но хотелось бы > самостоятельно придти к такому выводу :) Ну, могу попробовать ещё раз озвучить своё мнение по этому вопросу. Надо наверно начать с того, что sandman был написан разработчиками для облегчения процесса разработки, в то время как hasher был ориентирован в первую очередь на быструю и безопасную пересборку пакетов, пришедших из "непровереных источников". В sandman фиксируются все изменения пакета (спек-файл, тарболы, патчи), можно гибко управлять некоторыми параметрами сборки индивидуально для пакетов, есть поддержка нескольких базовых дистрибутивов (т.е. можно разрабатывать пакеты для, например, current sisyphus, master 2.2 и junior 2.2). В sandman также возможна паралельная сборка нескольких пакетов (в hasher это тоже можно сделать используя разные префиксы). Также для ускорения процесса пересборки есть (или сейчас сломана?) поддержка ccache, возможность повторного использования "песочниц" для сборки нескольких зависимых друг от друга пакетов. Плюс к этому всему - клиент-серверная архитектура, что позволяет держать один мощный сборочный сервер на группу разработчиков. Ещё большим преимуществом я считаю зависимость sandman только от apt, установленного в рабочей системе, да и то только на начальной стадии создания базовой системы в chrooted environment. С другой стороны sandman довольно сильно доверяет собираемым пакетам. Несмотря на то, что создание сборочной среды происходит в chrooted environment, пакеты устанавливаются от суперпользователя и от него же выполняются все postinstall скрипты. Чем это может быть чревато, думаю, об'яснять не надо ;-) hasher - "пакеторубка" (C) ldv ;-) В первую очередь (как _мне_ кажется) он задумывался как быстрая и безопасная разгребалка incoming'а. Всё операции выполняются от псевдопользователя (хотел по привычке добавить "в пустом read-only chroot'е" ;-) под fakeroot(1), используется целый комплекс мероприятий для защиты от возможного DoS (например ограничение времени сборки)... Также, hasher довольно сильно зависит от окружения, в котором работает, мне кажется, что он очень ALT- (точнее даже Sisyphus-) specific... Но зато при использовании hasher разработчик должен сам думать с какими параметрами его вызывать, где хранить исходные src.rpm'ы, следить за тем, чтобы не собирались несколько пакетов в одном префиксе и т.д. (но есть один большой плюс - гибкое управление целевой архитектурой - например я собираю свои ядра в hasher под i686, в sandman это можно сделать, но гораздо сложнее). Это всё - суб'ективное мнение меня как мантейнера нескольких пакетов. И конечно не последнюю роль тут играет тот факт, что sandman я настроил (ещё раз огромное спасибо Сергею Большакову за неоценимую помощь) ещё тогда, когда hasher не был написан ;-) Для себя я сделал такой вывод, если пакеты собираются от случая к случаю, если про cvs вы знаете только что "его используют", если не нужно ничего специфичного - hasher будет проще в обращении. Если есть много пакетов, с которыми часто работаете, если хочется упростить процесс сборки, если нужна история изменений и нужно несколько "дистрибутивов" - sandman будет удобнее. В любом случае - не попробуешь не узнаешь ;-) -- Regards, Sir Raorn. ------------------- Код в ntp, который обеспечивает этот resolving, плох. -- ldv in sisyphus@