Re: [devel] пакеты копировать нельзя

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 6760 bytes --]

On Mon, Feb 16, 2009 at 11:52:55PM +0300, Dmitriy M. Maslennikov wrote:
> 16 февраля 2009 г. 12:28 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > ...
> Такие рассуждения выглядят красиво. Но если оторваться от чистой
> математики и вернуться к практике, то, на мой взгляд, все выглядит
> несколько иначе.

Практические следствия модели могут быть ещё не вполне ясны.
Они проявятся при внедрении тестовой пересборки пакетов.

> Мне, как и большинству пользователей важен репозиторий в первую
> очередь РАБОТАЮЩИЙ. То есть с работающими на практике пакетами.

Нам нужен не только работающий репозитарий, но и пересобирающийся
репозитарий, причем мы будем фиксировать все (формально доступные)
изменения пакетов после тестовой пересборки (в том числе зависимости
тестово-пересобранных пакетов).

Пусть пакет 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 "работал"?  То есть он даже запускается, если вручную
проверять, а потом падает.  В этом смысле говорить про "работающие
пакеты" мне кажется не очень конструктивно.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]