[devel] уже давно не о документации

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 11:03:30PM +0300, Dmitry V. Levin wrote:
> Это зависит от постановки задачи.  Например, от того, сколько карманов в
> единицу времени требуется обрабатывать одновременно (в среднем и
> максимально).

Мне всё ещё не нравится термин "карманы", которому не дано определения,
и который, скорее, выражает смутные чаяния менее образованной части нашей
интеллигенции.  Что такой карманы?  Чем карман отличается от задания?

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

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

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

> Реализация параллельной обработки показала, что большой
> объем вычислительных мощностей требуется не только для сборки самих
> пакетов на вычислительных узлах, но также и для вычисления нового
> состояния репозитория с последующими проверками целостности.  Сейчас все
> такие вычисления централизованы, и мне очевидно, что система начинает
> заметно проседать уже при параллельном вычислении двух состояний разных
> репозиториев.

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