[devel] git-репозитарий для логов сборки
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Пт Ноя 9 01:48:45 MSK 2007
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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20071109/bfee16ad/attachment-0002.bin>
Подробная информация о списке рассылки Devel