On Sat, Aug 25, 2007 at 02:16:46PM +0400, Alexey I. Froloff wrote: > * Alexey Tourbin [070825 13:40]: > > Разруливать, по-моему, должен не столько товарищ, сколько maintainer. > > То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы > > ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"? И maintainer > > отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы". > Это АЦЦКИ медленно. Вот, например, thresh@ залил новый FLAC со > сменой API и одновременно NMU на несколько зависимых пакетов. > Или либа с новым SONAME и compat пакет. Если их перемещать по > одному, то будут новые unmet'ы в репозитарии и сломанная сборка. > Ждать ещё по несколько часов для каждого пакета? Я рассматриваю более пессимистическую ситуацию: maintainer направляет новый пакет и НЕ ЗНАЕТ, как изменятся характеристики сизифа на этом пакете. Ответственный maintainer, который заранее подготовил NMU, это хорошо, но технологичность должна подразумевать защиту от сбоев по пессимистическому сценарию. Опять же, я не против транзакции из нескольких пакетов, если все они проводятся одним человеком. Однако NMU настораживает. Техника получения NMU до конца не отработана. Насчет "будет медленно" не очень согласен. Входящий flac-*.src.rpm сейчас "задевает" 161 пакет, включая те приложения в которых FLAC для сборки по сути и не используется (а ставится только одна только библиотека libflac). > > > Насколько сложнее проверять и пересобирать пакеты "пачками"? > > Наверное, если нужно провести сразу несколько пакетов в виде транзакции, > > то наверное нужно предусмотреть специальную операцию "отправить на вход > > группу пакетов". > Поскольку из одного src получается больше-или-равно одного > бинарного пакета, принципиальной разницы я не вижу. Дело в том, что нужно уметь ответить на вопрос: КТО именно и ЗА СЧЕТ ЧЕГО именно сломал ЭТОТ пакет (который перестал собираться). Чем меньше будет неопределенности, тем лучше (будет понятно, что нужно откатывать, или хотя бы кого трясти). С другой стороны, хотелось бы, конечно, обеспечивать атомарную смену soname'ов в репозитарии. Но при числе вовлеченных maintainer'ов больше 2-3 это становится проблемно... Кстати смену soname'ов можно обнаруживать автоматически. Просто нужно сравнивать зависимости у пакетов, свежепротестированных пересборкой, и уже собранных пакетов. В общем, всякие разные штучки-дрючки можно замутить, когда пакет находится на подступах к сизифу. Тестирование пересборкой это только одна из них. К сожалению, работа управдома для меня достаточно непрозрачна, и, насколько я знаю, нигде на git.altlinux.org управдомовские скрипты не публикуются. Плюс есть ещё параллельные транзакции. От них ЗЕЛО голова болит, я их пока даже не обсуждал. Грубо говоря, начиная говорить о транзакциях, есть два подхода. Первый подход -- каждый пакет собирается и тестируется на логически "приватной копии" Сизифа. То есть каждый входящий src.rpm пакет берёт "длинный" read-lock на текущий сизиф, а "сводильщик" будет работать в режиме writer starvation. Другой крайний вариант -- один большой общий отстойник для всех, который может полностью или частично перемещаться в сизиф. Кстати это не настолько глупо, как может показаться с первого взгляда. Промежуточный вариант -- изоляция на уровне maintainer'а. Ну и что будет если при сведении "сводильщик" обнаруживает пересечения, тоже непонятно. Ладно, это уже вопросы на более отдалённое будущее, когда основные проблемы будут решены.