[devel] 4.1 FAILED srpm=rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm

[Alexey Tourbin]

On Sat, Mar 21, 2009 at 11:37:56AM +0200, Michael Shigorin wrote:
> On Fri, Mar 20, 2009 at 09:40:25PM +0300, Girar Builder robot wrote:
> > 2009-Mar-20 21:40:03 :: task #2974 for 4.1 started:
> > #1 build rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm
> > 2009-Mar-20 21:40:05 :: [i586] rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm: build start
> > 2009-Mar-20 21:40:05 :: [x86_64] rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm: build start
> > 2009-Mar-20 21:40:23 :: [x86_64] rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm: build OK
> > 2009-Mar-20 21:40:23 :: [i586] rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm: build OK
> > 2009-Mar-20 21:40:25 :: #1: rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm: package `rpm-build-thunderbird' version `2.0.0.21-alt0.M41.1' is not lesser than its version `2.0.0.18-alt1' in `5.0'
> > 2009-Mar-20 21:40:25 :: build check FAILED for #1
> > 2009-Mar-20 21:40:25 :: build check FAILED
> > 2009-Mar-20 21:40:25 :: task #2974 for 4.1 FAILED
> 
> Вот, опять споткнулся.
> 
> В 5.0 заброшенный thunderbird, из сизифа перекладывать никто
> пока не добрался, а в результате не будет обновления для 4.1.
> 
> Дорогая редакция!  Сделайте, пожалуйста, чтоб участвовать
> в проекте было опять интересно.  А то прям город гибедедейск
> -- пока развернёшься, половину улиц надо проехать.  На то ли
> тратить топливо в наши тяжёлые времена? :-)
> 
> Ещё раз предлагаю build -f.  Хоть в рамках добровольных дружин
> по поддержке бранчей, хоть ещё как -- но это ж ружья кирпичом
> чистить, требовать автоматом такого взаимодействия между людьми.
> Сами не умеете -- от других тем более не требуйте.

Ты предлагаешь отменить проверку на монотонное возрастание версий
в бранчах: V(4.0) <= V(4.1) <= V(5.0) <= V(sisyphus).  Вряд ли твое
предложение будет принято всерьез.

Проверку на монотонное возрастание версий реализовал на я, а ldv.
Я исходил из "суженной" модели репозитария, в которой в качестве
исходных данных есть только текущее состояние репозитария S_k (на
уровне отдельного бранча).  Если же учитывать монотонное возрастание
версий, то модель многократно усложняется: в качестве исходных данных
мы имеем упорядоченное множество состояний S_{i,k}, i=1..n; и выделенное
состояние S_{j,k}, j\in1..n, соответствующее текущему бранчу.

Короче, смысл всех этих странных слов -- добиться функциональной
зависимости, что от чего зависит.  Функциональная зависимость означает,
что когда на вход подаем одно и то же, то и на выходе должны получить
одно и то же.  Понятно, что монотонная проверка усложняет функциональную
зависимость, что от чего должно зависеть.  А в конечном счете можно
придти к абсурдному выводу, что всё зависит от всего (и тогда
большинство "интересных" моделей теряют смысл).

Тем не менее, проверка на монотонное возрастание версий по сути
правильная.  Drawback -- как бы странно, что состояние 4.1 вдруг
зависит от состояния 5.0.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20090321/253afd5a/attachment.bin>