On Sun, Feb 06, 2011 at 07:30:35AM +0300, Alexey Tourbin wrote:
> On Sat, Feb 05, 2011 at 11:03:30PM +0300, Dmitry V. Levin wrote:
> > Это зависит от постановки задачи.  Например, от того, сколько карманов в
> > единицу времени требуется обрабатывать одновременно (в среднем и
> > максимально).
> 
> Мне всё ещё не нравится термин "карманы", которому не дано определения,
> и который, скорее, выражает смутные чаяния менее образованной части нашей
> интеллигенции.  Что такой карманы?  Чем карман отличается от задания?

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

> Задание (в широком смысле) - это намерение модифицировать репозиторий
> методом сборки, замещения и/или удаления пакетов; намерение порождает
> процесс, который идёт по определенным правилам.  Правила нужны для
> поддержки целостности репозитория.  А именно, вычисляется характеристики
> репозитория до и после модификаии.  Модификация применяется, если после
> модификации характеристики не ухудшаются.  Намерение может быть
> отложенным: мейтенер вправе просмотреть результат, прежде чем окончательно
> подтвердить модификацию, т.к. некоторые характеристики сложно учесть
> формально.
> 
> Если про карманы говорят именно в этом смысле, то карманы - это всего
> лишь более навороченные задания.  Кирилл написал, что карманы нужны
> для тестовой пересборки репозитория с новым gcc.  Вообще-то задания
> должны предоставлять именно такую возможность: должна выполняться тестовая
> пересборка всех зависимых пакетов (как часть вычисления характеристик
> репозитория).  То, что тестовая пересборка зависимых пакетов до сих
> пор не реализована, не оправдывает новой терминологии.

Подготовка нового gcc -- это итеративный процесс.  Карманы первого рода
(см. выше) нужны для того, чтобы инициатор этого процесса (мейнтейнер gcc)
и его коллеги могли проводить полноценные эксперименты над репозиторием, в
котором gcc по умолчанию уже обновлен.

> С другой стороны, есть те, кто понимает под карманами что-то ещё более
> неопределенное - возможность что-то "бутстрапить", собирать пакеты с
> многократным замещением и в неопределенном порядке - экспериментировать
> до тех пор, пока там что-то не "сварится"... варить пакеты в кармане!
> Я считаю, что тут просто нет ясного намерения модифицировать репозиторий.
> Поэтому, кроме всего прочего, системы такого рода могут быть реализованы
> особенно эффективно вследстие того, что они могут находиться где-то
> в другом месте и минимально пересекаться со сборочной системой git.alt.

Наивно полагать, что системы типа git.alt могут быть реализованы каждым
мейнтейнером у себя под боком.  Для того git.alt и нужен, чтобы сделать
эту технологию доступной и удобной для коллективной разработки.

> > Реализация параллельной обработки показала, что большой
> > объем вычислительных мощностей требуется не только для сборки самих
> > пакетов на вычислительных узлах, но также и для вычисления нового
> > состояния репозитория с последующими проверками целостности.  Сейчас все
> > такие вычисления централизованы, и мне очевидно, что система начинает
> > заметно проседать уже при параллельном вычислении двух состояний разных
> > репозиториев.
> 
> Это можно подробнее обсудить, но тут был заметный прогресс, и это не
> главная проблема.  Более заметная проблема (или, лучше сказать, белое
> пятно) - это вычисление замыканий.  Грубо говоря, как узнать, какие пакеты
> пересобирать, даже если есть мощности для тестовой пересборки?  Апт
> довольно медленно вычисляет замыкания BuildRequires.  При наивной
> реализации замыкания BuildRequires для всех исходных пакетов будут
> вычиляться аптом минут 20 - даже если в результате не придется
> пересобирать ни одного пакета.

Значит, нужна менее наивная реализация.


-- 
ldv