On Tue, Sep 15, 2009 at 11:52:41PM +0400, Dmitry V. Levin wrote: > On Tue, Sep 15, 2009 at 11:17:28PM +0400, Alexey Tourbin wrote: > > On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote: > > > On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote: > > > > К сожалению, пока (до появления надлежащей реализации карманов?) > > > > некоторые транзакции и workflows сборочницей не поддерживаются. > > > > В частности, не поддерживаются транзакции, включающие в себя несколько версий > > > > одного и того же пакета (bootstrap-сборка). > > > > > > Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать > > > анметы. > > > > Я не знаю как поддержать такие транзакции. Точнее знаю. > > Пусть пакеты в задании пронумерованы 1..n. Предикат > > пересечения x(i,j), i=1..n, j=1..n, i > в пределах задания пакет с большим номером j пересекается > > с пакетом с меньшим номером i (по имени исходного пакета и/или > > по имени одного из бинарных пакетов). Тогда по смыслу пакет i > > нужно выбросить из плана задания, потому что он был нужен > > для бутстрапа пакета j. Пакет j в свою очередь может быть > > вытеснен пакетом с ещё большим номером. > > > > Пересечение проверяется для всех пар (i,j). Доказать что > > окончательный план транзакции не зависит от порядка, в котором > > проверяются пары (i,j). > > Лучше сразу после сборки подзадания j выкинуть результат сборки всех > подзаданий i Я думаю, что мейнтейнеру будет проще предсказать поведение сборочной > системы, если она будет следовать этому правилу. Если следовать этой логике, то сейчас после сборки каждого пакета нужно проводить полное промежуточное замещение в основном репозитории. Это не только дорого, но и встаёт вопрос, какие требования предъявляются к промежуточному репозиторию. Например собранные пакеты могут перетасовываться между исходными пакетами; если проводить строгие замещения, то можно быстро налететь на проблемы. Поэтому сейчас сборка идёт на repo + RPMS.hasher overlay, а план A0->A1 вычисляется только в самом конце. Я когда-то решил что ничего лучше придумать нельзя. С наскоку по крайней мере. А как сюда вписать дупы в пределах самого задания? Сейчас работает логика "в промежуточное состояние мы в принципе не вклиниваемся", а дупы просто запрещены. Поменять её на логику "в промежуточное состояние мы в принципе вклиниваемся" это очень круто. > > В общем мне это не нравится, я бо так не стал делать. Сейчас все > > транзакции прозрачны: результат сборки каждого пакета зависит от пакетов > > в репозитарии и дополнительно от пакетов с меньшими номерами, которые > > однако жо гарантированно попадают в репозиторий. Прозрачность как бы > > означает, что имея начальный репозитарий A0 и конечный репозитарий A1, > > мы имеем все данные, чтобы заново проиграть транзакцию на репозитории > > A0 и получить в результате идентичный репозитарий A1. А с бутстрапом > > такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как > > на основе A0 воспроизвести A1 повтрно. > > Нет, сейчас знания о A0 и A1 недостаточно для того, чтобы на основе A0 > воспроизвести A1 повторно. Для этого нужна дополнительная информация, > которая находится в задании A0->A1. Почему же недостаточно? Достаточно, с точностью до некоторых второстепенных атрибутов типа %packager. То есть мы смотрим какие новые пакеты есть в A1 и просто начинаем их собирать. По окончанию сборки удаляем старые пакеты и получается репозиторий идентичный A1. Порядок сборки играет роль, но его можно узнать из buildtime/mtime. Если бы даже порядок сборки был неизвествен, то его можно обнаружить перебором. То есть в принципе, плюс-минус тонкости, мы можем начать собирать на A0 и получить A1. А новую модель с бутстрапом в общем виде можно описать так. Собрать n пакетов, выбрать из них m пакетов, mA1 выполнен только с учетом m пакетов, то часть информации потерялась. То есть начать собирать эти пакеты заново и получить A1 уже нельзя даже в принципе.