On Fri, Nov 09, 2007 at 01:48:45AM +0300, Dmitry V. Levin wrote:
> Лог сборки - это свойство исходного пакета в данном репозитории для данной
> архитектуры.  Например, это можно представить в виде
> исходный_пакет/архитектура.

Точкой входа (top-level каталог) является имя src.rpm пакета.
типа
	.git/
	glibc/
	bash/
под каждым каталогом буедт что-то типа
	bash/
		SVR
		i586
		x86_64
это уже файлы; SVR -- это "чистая информация".  i586 и x86_64 --
это логи сборки.  Тут такая особенность, что мы не имеем права помещать
в репозитарий логи сборки от разных SVR, если речь идёт о синхронизации
основных архитектур.  И есть ещё эти неосновные архитетуры, которые не
нужно синхронизировать.  Если их как-то хранить, то опять усложняется
структура дерева фс.

Теперь к вопросу, как отличить фактический лог от тестового.
Косвенным признаком может стать изменение файла SVR.  Когда
файл SVR изменился, то в этом месте логи фактические,
а во всех случаях они тестовые.  Но этот признак плохо
соседствует с "неосновными архитектурами".

На это наслаивается ещё одна проблема.  Желательно уметь формально
отличать "успешные" логи сборки (зелёные) от "неуспешных" (красных).
Как сохранить информацию красный/зелёный (без заглядывания в лог)?
Фактические логи по определению всегда успешные (при синхронизации
архитектур), а статус тестовых логов i586 и x86_64 при очередной
тестовой пересборке может между собой отличаться.

То есть проблема такая: если брать примитивную структуру фс,
то реализация элементарных операций становится более сложной.
А более просто реализовать элементарные операции можно только
за счёт серьёзного усложнения структуры фс (так что метарепозитарий
становится интуитивно непонятным).