[devel] GHC-7.4

[Igor Vlasenko]

On Fri, Feb 10, 2012 at 08:44:45AM +0400, Vitaly Kuznetsov wrote:
> Мне непонятно, откуда в этой схеме будет появляться несколько версий
> одной библиотеки. Они будут собираться из разных исходных пакетов?

Да. Основное различие в значениях макросов GHC_VER, 
и опционально, GHC_SERIAL (обычно %nil; нужен, если вдруг придется
собирать несколько поколений с одной версией ghc).

> Если я правильно понял Дениса, то хочется получить следующий workflow:
> 1) Вышел новый ghc - собираем в репозиторий его и
> rpm-build-ghc-whatever
> 2) По одной пересобираем библиотеки с новым ghc (и вот тут как раз
> должны рождаться 2 версии)
> 3) Пересобираем приложения, проверяем что старые библиотеки никому
> не нужны

> 4) Пересобираем библиоткеки ещё раз, оставляем только новую версию.
В предложенной схеме в пункте 4 нет необходимости.
Можно просто удалить старые библиотеки. А можно и не удалять.

> В предложеной схеме, если я правильно понял, на шаге 2 нужно будет
> автоматизированным способом создать клоны исходных пакетов с
> библиотеками.

Да, + еще автоматизированно обновляться из Hackage
и инструменты подготовки транзакций для заливки.

> Можно, наверное, пойти другим путём: собирать все возможные версии
> библиотеки (точнее - все, которые собираются) из одного спека. При
> этом потребуется устроить циклы в %build и %install, ну да это не
> сложно.

Это подход к автоматизации, при которой мы по сути 
хотим хранить скрипты автоматизации в спек файле.
IMHO, это не эффективно, так как придется руками хардкодить
списки и т.д., внешние скрипты эффективнее, IMHO.

> Можно также предположить, что почти всё с новым ghc собирается. Это
> означает, что нужно лишь придумать возможность собрать
> compat-библиотеку и держать в Сизифе несколько ghc. Спеки же самих
> пакетов можно не менять.

Я тоже сначала думал о таких подходах, но если спеки самих
пакетов не менять, то у нас сразу же возникает шаг 4)
выше -- обязательная всеобщая пересборка. 
А всеобщая пересборка -- вещь очень коварная, когда семеро одного ждут.
Если у нас 20 ghc пакетов -- этот аспект не заметен.
Если у нас 90 ghc пакетов, как сейчас - это еще терпимо.
Но если у нас будет 900 ghc пакетов (не обязательно в Сизифе;
может быть, в отдельной песочнице автоимпорта из Hackage)
то необходимость всеобщей пересборки на шаге 4) обязательно
выстрелит в ногу и рано или поздно парализует работу.

Вспомним героические усилия для обновления питона.

-- 

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