On Mon, Feb 16, 2009 at 11:52:55PM +0300, Dmitriy M. Maslennikov wrote: > 16 февраля 2009 г. 12:28 пользователь Alexey Tourbin написал: > > ... > Такие рассуждения выглядят красиво. Но если оторваться от чистой > математики и вернуться к практике, то, на мой взгляд, все выглядит > несколько иначе. Практические следствия модели могут быть ещё не вполне ясны. Они проявятся при внедрении тестовой пересборки пакетов. > Мне, как и большинству пользователей важен репозиторий в первую > очередь РАБОТАЮЩИЙ. То есть с работающими на практике пакетами. Нам нужен не только работающий репозитарий, но и пересобирающийся репозитарий, причем мы будем фиксировать все (формально доступные) изменения пакетов после тестовой пересборки (в том числе зависимости тестово-пересобранных пакетов). Пусть пакет A был собран в родной среде, и потом идёт пакет B. Тогда идёт тесовая пересборка репозитария с пакетом B, в том числе пересобирается пакет A. Если у тестово-пересобранного пакета A изменились зависимости, то это изменение зависимостей можно однозначно квалифицировать как влияние пакета B. Если же пакет A и вовсе перестал собираться, тогда можно однозначно утверждать, что пакет B ломает сборку пакета A. Всё это пропадает, если пакет A был собран где-то ещё. Тогда ни изменение зависимостей у пакета A, и ни поломку сборки пакета A уже нельзя однозначно связать с влиянием пакета B. > Обеспечить это можно только полноценным тестированием пакетов ДО > помещения их в основной репозиторий. При этом полной гарантии дать, > конечно, нельзя, но в целом пакет, прошедший тестирование, гораздо > более надежен, чем тот, который не проверялся вообще. Все рассуждения > данные выше направлены не на это свойство, а на гарантию повторяемости > процесса сборки пакета. С точки зрения удобства ведения репозитория > это, конечно полезно, но для пользователя репозитория это совсем не > так важно. Так, для пользователя отлично пересобирающийся, но не > работающий новый пакет foo-0.1-alt1 гораздо хуже не способного > пересобраться, но РАБОТАЮЩЕГО пакета foo-0.1-alt1. Еще же интереснее > гарантировать и пересобираемость, и работоспособность пакетов. Работоспособность в широком смысле гарантировать нельзя; на то она и модель, что фиксирует лишь формальные характеристики. Но эта модель позволяет очень тонко анализировать взаимное влияние между пакетами. В общем, модель не может решить все проблемы, но с её помощью можно делать некоторые выводы, а также она сама по себе интересна как инструмент для анализа. > Когда мы думали над похожей тематикой, мы решили пожертвовать > сериализацией сборки пакетов (сборка пакета A -> добавление пакета A в > репозитарий -> сборка пакета B), разрешив прошедшим сборку пакетам > временно попадать в тестовый репозиторий. Это мелкое мошенничество. Если нет сериализации, то нельзя зафиксировать взаимное влияние между пакетами. А если нельзя зафиксировать взаимное влияние между пакетами, тогда нельзя однозначно сказать, какой пакет ломает другие пакеты (или вообще "плохо влияет"). Тогда мы возвращаемся к старой модели incoming + еженедельная тестовая пересборка сизифа. Всю неделю создается "временный репозитарий", а в конце недели идёт "тестовая пересборка". Но по результатам тестовой пересборки уже нельзя однозначно определить, кто кого сломал. А модель с сериализацией позволяет точно определить, кто кого сломал, и, более того, реализовать pre-condition: не пропускать пакеты, которые что-то ломают. > И только после этапа > тестирования пакеты попадают в основной репозиторий (если не порождают > unmet'ов и проходят прочие проверки). При этом таких тестовых > репозиториев можно создавать сколько угодно (для каждой задачи свой > отдельный репозиторий - box). В каждый можно собирать пакеты, > основываясь на текущем состоянии репозитория и состоянии самого box'а. > При этом принятие пакетов из box'а в репозитарий происходит по > завершению тестирования сериализованно (атомарно). В терминах girar-builder получается, что box -- это задание (task). В задании может быть несколько пакетов. То есть в принципе можно "варить" некоторый набор изменений сколько угодно (то есть дорабатывать пакеты, если обнаруживаются ухудшения). Задание применяется транзакционно. В girar-builder будет реализована довольно сложная стратегия мёржа, которая должна отвечать за окончательную сериализацию задания. Стратегия мёржа "применяет" задание к репозитарию. В зависимости от некоторых базовых условий, стратегию мержа можно реализовать немного по-разному. В частности, мёрж может подразумевать, что перед помещением пакетов задания в репозитарий их нужно заново пересобрать. Короче, сериализация возможна, хотя это не очень просто. [И ещё, к счастью, сериализация заданий -- это головная боль отдельно взятого человека.] > В нашем случае мы, конечно, теряем "историю репозитория", так как > повторить процесс сборки в том же виде невозможно (неизвестно в какой > последовательности собирались пакеты в различные box'ы и какое > состояние было в этот момент у репозитория), но зато можем обеспечить > процесс тестирования (как подключение box'а и репозитария > одновременно, установку пакетов из box'а и непосредственно > тестирования), что и повлияло на наш выбор. Мне не очень понятно, что такое "непосредственное тестирование". То есть это значит ставить пакеты на рабочую машину, запускать программы и смотреть, работают они или не работают? Это не технологично, а при числе пакетов порядка 10^4 это вряд ли возможно. Технологично можно только смотреть на формальные характеристики, которые позволяют судить о базовой работоспособности пакетов. Например, если все пакеты устанавливаются (в частности, нет анметов) и если все пакеты удается тестово пересобрать, тогда это неплохой расклад, чтобы применить транзакцию и ехать дальше уже на новом репозитарии. > Повторюсь, что оправданием такой потери служит именно тот факт, что > пользователям необходимы пакеты прежде всего работающие, а не > полученные строго математически с возможностью повторить процесс > получения. Ну и кроме того, я не могу придумать ситуации, когда > жизненно необходимо знать "историю репозитория" (в указанном вами выше > смысле), хотя и допускаю возможность того, что я чего-то недопонимаю. Как получить "работающие пакеты"? Например, у меня f-spot через некоторое время после запуска, всё время разное, вываливается со stack trace. Что можно предпринять по части технологии сборки пакетов, чтобы f-spot "работал"? То есть он даже запускается, если вручную проверять, а потом падает. В этом смысле говорить про "работающие пакеты" мне кажется не очень конструктивно.