Re: [devel] ccache(1) to prop things up

[Alexander Bokovoy <ab@altlinux.org>]

2012/2/9 Alexey Tourbin <at@altlinux.ru>:
> On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote:
>> Но эта система была направлена на строгий учет изменений и контроль
>> целостности репозитория.  А реализовать ее не удалось, потому что это
>> требовало сборочных ресурсов, которые оказались фирме альт линукс не по
>> карману.  Возможно, стратегической ошибкой было и то, что мы не хотели
>> использовать ccache(1) по крайней мере для тестовой пересборки, а это
>> могло бы значительно удешевить процесс.
>
> Когда в 2002 году ab и sb разрабатывали sandman (прототип сборочной
> системы), они предлагали, насколько я помню, монтировать внутрь чрута
> глобальный раздел с ~/.ccache.  На это есть два возражения.  С точки
> зрения безопасности это дает интерференцию между пакетами.  С точки
> зрения распределенной архитектуры это требует синхронизацию кеша.
>
> Оба возражения снимаются, если для каждого пакета поддерживать
> персональный "сикеш".  Более того, поскольку сборка пакета идет обычно
> идет в каталоге ~/RPM/BUILD/%name-%version, а при компиляции с флагом -g
> учитываются пути к исходным файлам, то персональный сикеш можно сразу же
> ограничить не только именем пакета, но и версией.
>
> То есть можно было бы сделать файлы типа ccache/%name-%version.tar.gz,
> и гонять их зад-назад вместе с src.rpm.
>
> Если преследовать еще более строгую схему, которая исключает влияние
> сикеша по крайней мере на "настоящие" пакеты, которые поступют в
> репозиторий, то можно сделать следующее.  Пакеты всегда собираются
> через сикеш.  Сборка "настоящего" пакета (внутри задания) просто
> будет выполняться при пустом ~/.ccache (фактически в режиме write-only),
> но результат сохраняется для последующих тестовых пересборок (в режиме
> read-write).
В качестве (не совсем уж и альтернативного) варианта можно
использовать вариацию схемы, которая используется в Fedora. Для каждой
сборочной цели (репозитория) сборочная система ведет кэш базовой
системы ("buildroot"). Этот кэш базовой системы живет несколько
дольше, чем обычно из-за двухстадийной схемы попадания пакетов в
репозитории:  из групп (stable + updates) и (updates-testing) кэш
базовой системы формируется только из первой группы, с возможностью
замещения определенных пакетов в нем собранными, но неотправленными в
репозитории. Стоимость формирования такого кэша для одной архитектуры
-- 5-7 минут, даже если он регенерируется каждый день.

Если мы из используемого при сборке кэша ccache будем собирать разницу
в пакеты foo-ccacheinfo по аналогии с debuginfo, то можно будет
генерировать такой кэш базовой системы и для ccache. Или просто
устанавливать принудительно предыдущую версию foo-ccacheinfo и
зависимости при сборке пакета.

> Я проделал некоторые замеры.  Повторная сборка elinks с сикешем идет
> примерно на 20% быстрее, а повторная сборка apt - в 2 раза.  То есть
> наибольшая выгода, очевидно, будет на больших пакетах с Си++ кодом.
> В первом приближении (пальцем в небо) сикеш может ускорить тестовую
> пересборку репозитория в 2 раза.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
/ Alexander Bokovoy