On Mon, May 18, 2009 at 02:24:47PM +0400, Victor B. Wagner wrote: > On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote: > > > Потому что такова семантика сборки заданий: они обладают семантикой > > транзакции. Если задание собрано успешно, то оно переводит репозитарий > > в новое состояние, и сборка следующего задания начинается уже на новом > > репозитарии. Нельзя начинать собирать несколько заданий на старом > > репозитарии и потом "сводить" несколько результатов сборки в один новый > > репозитарий. Это может закончиться очень плохо. > > 1. Будет ли это "очень плохо" своевременно диагностировано? > 2. С насколько высокой вероятностью это "очень плохо" может случиться? > > А то может быть ждать десять раз по два часа плюс один раз - семнадцать > (когда "очень плохо - случилось, и пришлось откатываться и строить все > последовательно) будет несколько эффективнее, чем 11 раз по 15 часов? Я считаю, что принципиально важно обеспечить транзакционную семантику сборки заданий, и существующая реализация просто исходит из этого. Выполнение задания -- это попытка перевести репозитарий из старого состояния в новое состояние. Сборка следующего задания происходит уже на новом репозитарии (если предыдущее задание было выполнено успешно) или же целиком на старом репозитарии (если предыдущее задание завершилось с ошибкой). "Сводить" несколько заданий на логическом уровне нельзя в любом случае. Условия замещения пакетов могут быть слишком нетривиальными. Мы ведь допускаем произвольную перетасовку подпакетов между пакетами, а равно и полное замещение пакетов по подпакету, и при этом ещё нужно уметь проверять ACL (потому что существуют shared tasks, которые могут формироваться разными людьми). Корректно реализовать все эти процедуры нам пока удалось только для схемы A->B, где A - старое/текущее состояние репозитария, B - новое состояние репозитария. Эта схема предполагает явную сериализацию заданий. > Вообще, с очевидность МОЖНО собирать несколько заданий на старом > репозитарии и потом их сводить, при условии что эти задания от > результатов друг друга абсолютно независимы. Собирать можно, сводить нельзя. :) > Понятно, что есть такие пакеты, от которых зависит практически все - > filesystem, toolchain, базовые библиотеки. С ними почти ничего не > запараллелишь. Но что мешает запараллелить, например, сборку > какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни? > Или там сборку двух mail transfer agent-ов которые с точки зрения > некоторых дистрибутивов принципиально не могут использоваться > одновременно? Потому что нельзя предсказывать будущее. Можно лишь с некоторой вероятностью его частично вычислить, в надежде, что если будущее наступит именно таким, то на этом удастся сэкономить. Когда мы начинаем собирать задание, мы исходим из того, что о пакетах в этом задании нам ничего неизвестно. Это моя принципиальная позиация, если хотите. У ldv на этот счет другая, но не принципиальная позиция. Существует модель данных, которая в принципе делает возможным опережающую спекулятивную сборку пакетов. Эта модель данных описывается формулой B(S,C)->P где B -- процедура сборки пакета (build, hasher), S -- исходный код пакета (src.rpm), C -- содержимое сборочной среды (chroot), P -- собранные пакеты. Смысл этой формулы в том, что она устанавливает функциональную зависимость: результат сборки пакета зависит только от его исходников и содержимого сборочного чрута. В принципе это дает возможность выполнять опережающие параллельные сборки и потом смотреть, годится ранее собранное добро или же его надо заново пересобирать. Эта модель по сути уже реализована. Когда задание завершается с ошибкой, то в нём сохраняется информация о среде сборки. При возобновлении задания повторная пересборка некоторых пакетов может не потребоваться. Вот в каком виде эта информация представлена. Рассмотрим задание 6670 с пакетом perl-Class-Accessor. $ rsync -vaP git.altlinux.org::tasks/6670 $TMPDIR/tasks/ $ cd $TMPDIR/tasks/6670 $ find -name 'chroot_*' ./build/1/x86_64/chroot_base ./build/1/x86_64/chroot_BR ./build/1/i586/chroot_base ./build/1/i586/chroot_BR $ head ./build/1/x86_64/chroot_base SysVinit 2.86-alt2 x86_64 SysVinit-2.86-alt2.src.rpm 920f28e5ee12b122331eb5732964f0871a629eb7 alt-gpgkeys 0.7-alt2 x86_64 alt-gpgkeys-0.7-alt2.src.rpm 9f26e3268aabb7dad4d0860d663d66aa62171000 alternatives 0.4.1-alt2 noarch alternatives-0.4.1-alt2.src.rpm 7d06d5c571995c00b4fa499c2636ab3868778266 autoconf-common 0.2-alt1 noarch autoconf-common-0.2-alt1.src.rpm bfe73e65a4471aae6c5be95520953502bc60d69f autoconf_2.60 2:2.63-alt4 noarch autoconf_2.60-2.63-alt4.src.rpm 4f4f3fc50d82a617e2cf184f4279622ec372bff8 automake-common 0.2-alt1 noarch automake-common-0.2-alt1.src.rpm 1fb582eed4ecfd8a4d2db6ebd41ac7f2e4775c5e automake_1.11 1.11-alt1 noarch automake_1.11-1.11-alt1.src.rpm 73d43cb1b422e030bd6e08bd20a4997e788a0765 basesystem 1:sisyphus-alt17 noarch basesystem-sisyphus-alt17.src.rpm 71126abe4f8918d6e34bc7a47cbf606e0420dae8 bash 3.2.39-alt2 x86_64 bash-3.2.39-alt2.src.rpm b04ff27110379e289ba89e8213e9bbe2eeaaf3b9 binutils 1:2.19.51.0.2-alt1 x86_64 binutils-2.19.51.0.2-alt1.src.rpm ced2379c393a4380f8088ff37e98aa28d48c1dcc $ head ./build/1/x86_64/chroot_BR perl-devel 1:5.8.9-alt2 x86_64 perl-5.8.9-alt2.src.rpm 5b75802744adf0d9674451d251ee8125fc35b9b8 $ Здесь явно фиксируется среда C сборки пакета -- базовая часть сборочного чрута (одинаковая для всех пакетов) плюс дополнительные пакеты, которые являются замыканием BuildRequires. В общем, модель есть, но реализовать на основе этой модели параллельную сборку с сериализацией при сведЕнии -- это отдельная и достаточно сложная задача.