[devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

On Wed, Jul 09, 2008 at 01:20:32PM +0700, Mikhail Gusarov wrote:
> Twas brillig at 04:02:04 09.07.2008 UTC+04 when at на altlinux.ru did gyre and gimble:
> 
>  AT> Интересно, как лучше всего поступать в подобных ситуациях (с точки
>  AT> зрения логики проверок в сборочной системе и с точки зрения
>  AT> организации совместного "перехода").
> 
> Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
> тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
> транзакцией перемещаются в testing.

Что такое "варятся"?  Дело в том, что собранные пакеты должны быть
жестко привязаны к содержимому чрута, в котором они собрались.

B(S,C)->P
B - функция сборки, релизуемая хешером,
S - исходный код (src.rpm пакет),
C - chroot (базовая сборочная среда + BuildRequires, установленные в чрут),
P - собранные пакеты на выходе.

"Жестко привязаны" означает, что мы отслеживаем взаимное влияние между
пакетами.  Если содержимое чрута изменилось, то для пакета S требуется
либо тестовая пересборка (если он уже находится в репозитарии), либо
полная пересборка (если он ещё только "варится" на подходах к
репозитарию).

В этом смысле нельзя "варить" нечто неопределённое, а "пакет" -- это
определённо тройка <S,C,P>.  Пакеты не могут просто лежать и ждать,
пока они все вместе станут устанавливаемыми -- все переходные состояния
должны быть зафиксированы.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080710/9bfbc7dd/attachment-0002.bin>