[devel] GHC-7.4

[Igor Vlasenko]

On Tue, Feb 14, 2012 at 01:34:10AM +0400, Денис Смирнов wrote:
> IV> Даже если версия XYZ не изменилась, при необходимости внести
> IV> изменения в ghc полетят его provides -
> 
> Да, действительно. Только тогда получается что мы не можем просто
> пересобрать ghc (ибо он предоставляет provides, нужные другим пакетам). И
> любая попытка пересборки ghc потребует сборки его под новым именем. 
> 
> Причем это вызовет путаниук у пользователей -- 7.0.1.1, это 7.0.1 с serial
> 1, bkb 7.0.1.1 c serial %nil?

Надо просто вносить версию (и ,опционально, serial) в %name, при чем
по разному записывать. Например, верся ghc слитно без точки,
а если есть сериал, то отделять его точкой (запятой, другим символом)
тогда будет 
ghc701-utf8-string (serial=%nil)
ghc701.1-utf8-string (serial=.1)
либо использовать текстовый serial,
ghc701rel2-utf8-string (serial=rel2)
т.е. ghc701rel2 = 7.0.1-alt1
 
> Сами по себе гигантские транзакции страшны не размерами, а тем, что при
> обновлении ghc у нас часто половина пакетов будет не собираться.
> Кстати сами по себе гигантские транзакции все равно никуда не денутся.
> Скажем что будет если пытаться обновить ghc-utf8-string, или любой другой
> пакет с большой иерархией зависимостей?

Если пытаться обновлять, то да. 
но мы такие вещи хотим собирать параллельно.

Это в старой парадигме мы все пересобираем (гигантскими) транзакциями.
В новой мы все собираем рядом.

т.е. (условно) собрать рядом с ghc701-x-string = 0.3.6-alt1
пакет ghc701-x-string-v0.4.0 = 0.4.0-alt1
и они станут рядом не конфликтуя.

А я в скрипты автоматизации внесу логику,
что если программа marmelad собиралась с ghc701 и ghc701-x-string-v0.4.0,
мы ее хотим пересобрать с ghc745, с котром штатно собран 
ghc745-x-string = 0.4.0, то умный скрипт сам заменит в BuildRequires:
ghc701-x-string-v0.4.0 на просто ghc745-x-string.

Более того, с поддержкой cabal умный скрипт заменит 
ghc701-x-string-v0.4.0 и на ghc745-x-string = 0.4.1,
 если версия  0.4.1 входит в допустимый дапазон.

Мораль:

Модули тоже надо иметь возможность размножать по их
версии/serial (по умолчанию %nil).

По мере роста пакетов неизбежно придем к ситуации,
когда пакету A нужна версия v1 библиотеки C, 
а пакету B нужна версия v2 библиотеки C,
и собирать надо обе версии. Типичная, кстати для
java ситуация, поскольку средства сборки поощряют.

Поэтому надо иметь возможность собирать и
ghcXYZ-x-string, и ghcXYZ-x-string-vA.B.C,
и ghcXYZ-x-string-vA.B.C-rel2
в случае такой необходимости.

А если нет необходимости, то будет просто ghcXYZ-x-string.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine