[devel] giter-factory

[Alexey Tourbin]

On Thu, Aug 30, 2007 at 01:55:53AM +0400, Dmitry V. Levin wrote:
> > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую
> > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет
> > и дальше уже можно узнать его BuildRequires зависимости, как раньше.
> 
> Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет.
> Т.е. в данном случае srpm-пакет есть.
> Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся.

Мне так неудобно думать. :)  "Собрался src.rpm пакет в самом конце"
это слишком нетрадиционно.  Нужно либо целиком отказываться от src.rpm
пакетов как класса, либо (с точностью до 1-1 соответствия) допускать,
что src.rpm есть на входе.

> > Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm
> > пакета не слишком сильно меняются в зависимости от среды, в которой был
> > выполнен rpm -bs.  То есть, не на столько сильно, чтобы кардинально
> > менять список пакетов в билдруте при "незначительном" изменении
> > репозитария.
> Как правило, мы можем на это рассчитывать, не так ли?

Мы должны рассчитывать, что BuildRequires зависимости src.rpm пакета
фиксированы с точностью до версий в пределах архитектуры.

К примеру, зависимость BuildRequires: apache2 >= %apache2_version
является в этом отношении допустимой.  То есть при прохождении новой
версии пакета apache2 билдрут изменится в части подпакетов apache2,
то есть мы обнаруживаем что пакет с таким BuildRequires подлежит
пересборке.

BuildRequires зависимости в пределах архитектуры означают что
напр. можно писать

%ifarch arm
%def_without not_yet_package
%else
%def_with not_yet_package
BuildRequires: not_yet_package
%endif

Это уже означает отказ от src.rpm пакетов, потому что их зависимости
отличаются на разных архитектурах; но констрейнты о которых я говорю
сохраняются.

Недопустимыми BuildRequiers зависимостями являются зависимости типа
BuildRequires: %(rpm -qR libxml2)
BuildRequires: %([ $RANDOM -lt 32 ] && echo foo || echo libbar-devel)

С ними ничего нельзя сделать, и вся идея оказывается фальсифицированной.
Тем не менее, нет другого способа достаточно быстро узнать, что нужно
тестировать пересборкой в связи с поступлением очередных пакетов.

Короче, при полном отказе от src.rpm пакетов можно per-arch кешировать
некоторую часть его хедера.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20070830/81fa78ed/attachment-0001.bin>