On Thu, Nov 08, 2007 at 10:03:28PM +0300, Alexey Tourbin wrote: > On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote: > > Сборка транзакции (A) происходит следующим образом: > > - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra); > > использование ссылок делает эту операцию дешевой; > > - на этом снапшоте выполняется сборка --with-stuff исходных пакетов > > транзакции; если хотя бы один не собрался, то транзакция отменяется > > (в первой реализации сборочной системы не вижу смысла оптимизировать > > эту часть); > > Здесь есть тонкость: сборка --with-stuff второго и последующего пакетов > транзакции идёт со СТАРЫМИ contents_index_bin и contents_index_all. > То есть практика сборки --with-stuff потенциально может давать > неправильныме зависимости -- сразу же после фиксации транзакции > второый и последующие пакеты при тестовой пересборке могут получить > отличающиеся зависимости. Так что здесь есть несколько подходов: > 0) забить; 0a) пока забить; 1) делать в хешере локальный > contents_index_bin/all; 2) формировать временный сизиф после каждого > пакета транзакции и вести сборку уже на нём. Это всё равно не до конца > решает вопрос, если зависимостями между пакетами в транзакции > топологически не упорядочены (то есть напр. при сборке первого пакета в > транзакции используется старая сборка одного из последующих пакетов). Транзакция состоит не просто из множества исходных пакетов, а из списка исходных пакетов, т.е. это множество линейно упорядочено мантейнером. Для решения вопроса зависимостей, порождаемых под влиянием contents_index, можно действительно выбрать один из нескольких вариантов: - формировать contents_index по окончании сборки каждого пакета в транзакции; - формировать временный сизиф по окончании сборки каждого пакета в транзакции; Кроме того, можно собирать пакеты транзакции в два прохода (второй после проверки на анметы), но это не альтернатива вышеперечисленному. [...] > Имеется такая "структура коммитов" в метарепозитарии: > > * Rb (HEAD) > | > * ... > branch Ra' * | > `* Ra > > Я на самом деле всегда об этом думал в терминах специальной "стратегии > мёржа" метарепозитария, и эта идея казалась мне полдотвороной. Теперь > предлагается вместо мёржа делать ребейс. Вообще-то ребейс хуже мёржа, > но в данном случае речь идёт примерно об одной и той же алгебраической > операции. Мы хотим "насадить" изменение Ra->Ra' "сверху" на Rb. Честно говоря, я пока не вижу способа реализовать merge, который не есть по сути rebase. > То есть имеются изменения Nab=Ra->Rb' и Naa'=Ra->Ra'. > Можно ли их совместить "без конфликтов"? > > (Важное замечание. По сути речь идёт КРИТЕРИИ ВОЗМОЖНОСТИ мёржа/ребейса. > Этот критерий говорит о том, что эта операция ЛИБО ВОЗМОЖНА, ЛИБО > НЕВОЗМОЖНА. Это замечание можно переформулировать так: нельзя > ребейсить что угодно на что угодно.) Чем отличается критерий возможности rebase от критерия возможности сборки вообще? По идее, изменение Ra->Ra' можно преобразовать (rebase) в Ra->Rb', если транзакцию A можно собрать на репозитории Rb. [...] > Но можно смотреть немного по-другому. Здесь нужен ещё один слой защиты > от "частичного удаления" src.rpm пакетов. То есть должна быть > алгебраическая операция "удалить src.rpm" пакет. src.rpm пакет может > быть удалён только полностью, то есть в виде всех своих подпакетов. > А новый src.rpm может быть добавлен тоже только полностью, в виде всех > своих подпакетов. Видимо, да. [...] > > - предпринимается попытка применить успешно собранную транзакцию к Сизифу > > по вышеописанному алгоритму, см. (*). > > Это рекурсивно что ли получается? Скорее итеративно. > > Из этого описания можно сделать выводы о том, что нужно для обработки > > транзакции: > > - бинарный репозиторий Сизиф для сборки пакетов; > > - быстрое формирование нового бинарного репозитория Сизифа на основе > > предыдущего и новых пакетов (есть ли у нас необходимые средства?); > > Насколько быстрое? Быстрее чем среднее время сборки пакета. > Думаю что достаточно быстрое имеется. В каком виде? > > - корректное вычисление анметов (действующий алгоритм apt-cache unmet, > > по всей видимости, игнорирует конфликты); > > По крайней мере, если новый репозитарий правильно сформирован, то > 'apt-cache unmet' помогает обнаруживать бездумную/unintented смену > сонейма. Это отдельная проблема. Просто она всплыла в процессе обдумывания, и я отметил её. В первом приближении можно пренебречь. > > - быстрое вычисление подмножества исходных пакетов Сизифа, для сборки > > которых требуется пакеты из указанного подмножества бинарных пакетов > > Сизифа (у нас сейчас нет такого алгоритма); > > 30 минут на машине класса mash (см. мой query-rebuild.git). > Но это может быть намного быстрее на каком-нибудь Core2Duo, > и, следовательно, более приемлемо. В машинах класса mash измерять уже не интересно, но 30 минут -- это довольно много. > > - статистика сборки исходных пакетов Сизифа должна быть частью Сизифа. > > Да. Частью метарепозитария. То есть нужно знать когда и в каком виде > пакет последний раз собрался и кое-что ещё. В моих рассуждениях было достаточно знать про каждый исходный пакет в Сизифе Ra, собирался он или нет. Зачем может быть нужно что-то ещё? > > Формулировка "транзакция откладывается" означает, что дальнейшая обработка > > транзакции невозможна без вмешательства извне. На практике это может > > означать отмену транзакции, дополнение транзакции новыми исходными > > пакетами (фактически формирование новой транзакции на основе отложенной), > > или действия уполномоченных лиц по преодолению причин, из-за которых > > транзакция была отложена. > > Чем мёрж хуже ребейса. Процедура, согласно которой изменение A, первоначально сделанное для репозитория Ra, "проигрывается" на репозитории Rb, называется rebase. Если хочешь, называй это merge, я не против, но rebase, как мне кажется, лучше отражает суть происходящего. > При мёрже в метарепозитарии явно остаётся > информация, что нечто сломалось и потом починилось. Это ИНТЕРЕСНО. Если во время rebase что-то сломалось, то это уже не совсем чистый rebase. > При ребейсе эта информация исчезает, и кажется, что как-будто всё > само шло хорошо и гладко. Наверное, можно сохранять промежуточные состояния жизни транзакции, если это интересно. Я пока не вижу, зачем это может понадобиться. -- ldv