On Fri, Nov 09, 2007 at 01:30:12AM +0300, Alexey Tourbin wrote:
> On Fri, Nov 09, 2007 at 01:08:40AM +0300, Alexey Tourbin wrote:
> > > В моих рассуждениях было достаточно знать про каждый исходный пакет в
> > > Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?
> > 
> > Ну например ты писал, что имеешь привычку сравнивать логи сборки
> > пакетов.  Вот в метарепозитарии например можно хранить логи сборки
> > пакетов.  Тогда систематическое сравнение логов сборки станет простой
> > процедурой.
> > 
> > Хотя дело здесь не в логах, лог -- это плохой пример.
> 
> Кстати, логи можно складывать в отдельный git-репозитарий и публиковать
> его!  git должен дать большую экономию по дисковому пространству.

Особенно когда используется --nprocs=1.

> В случае с логами видна одна проблема, котороя существует
> и в метарепозитарии (точнее, в моей голове).
> 
> Нужно различать "начальный" и все последующие "тестовые" логи сборки.
> Начальный лог сборки -- это тот лог сборки, который ФАКТИЧЕСКИ
> соответствует собранному пакету в сизифе.  У нас ведь не принято
> пересобирать пакеты просто так, то есть пмы не пересобираем пакет,
> даже если при тестовой сборке в новой среде у него немного отличаются
> зависимости (пока они не станут анметами).
> 
> Вопрос здесь в том, что для каждого пакета желательно отдельно хранить
> начальный и все последующие тестовые логи сборки: log1 и log2.
> При этом log1 создаётся один раз и навсегда для сборки данного релиза
> пакета, а log2 обновляется при каждой тестовой пересборке.
> 
> Что это дает?  Сделав "diff -u log1 log2", мы увидим, чем отличается
> фактический лог от последнего тестового.  Сделав же "git-whatchanged
> -p log2", мы увидим, как изменялся log2 в процессе эволюции сборочной
> среды.
> 
> Только здесь всё равно что-то не сходится.  "git-whatchenged -p log2"
> будет работать "плоховато", в том смысле, что при каждом новом релизе
> пакета log2 будет удаляться.
> 
> Поэтому упрощенный вопрос: как хранить логи сборки пакетов, с учетом
> того, что желательно иметь простой способ отличать фактический лог от
> тестового?

Отличать лог фактической сборки от последующих тестовых можно с помощью
тэгов, например,
git log "$(git describe --abbrev=0)..HEAD"

> То есть какой должен быть расклад файлов/каталогов в
> git-репозитарии логов сборки?  А с учетом предполагаемой синхронизации
> основных архитектур?

Лог сборки - это свойство исходного пакета в данном репозитории для данной
архитектуры.  Например, это можно представить в виде
исходный_пакет/архитектура.


-- 
ldv