Re: [devel] GHC-7.4

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

On Thu, Feb 09, 2012 at 02:28:23AM +0400, Денис Смирнов wrote:
> On Mon, Feb 06, 2012 at 05:32:55PM +0200, Igor Vlasenko wrote:
> IV> Хотел бы предложить помощь. Могу заскриптовать работу с srpm пакетами 
> IV> для поддержки нескольких версий ghc. Еще в прошлом году собирался
> IV> так сделать, но попал в положение Буриданова осла, когда 
> IV> было несколько вариантов, как это будет выглядеть на практике,
> IV> со своими достоинствами и недостатками, и так и не выбрал, как 
> IV> должно выглядеть multighc полиси.
> IV> Т.е. надо выбрать схему работы, а я ее с удовольствием заскриптую.
> 
> А какие варианты ты преддполагаешь?

Подумав еще раз, выбрал и хочу предложить следующее:

Каждое приложение (вроде xmonad) в установленной системе одно,
Библиотек (вроде ghc-zlib) в системе может быть несколько,
неконфликтующих, равноправных, с названиями 
ghcXYZ(.T)-zlib, где XYZ - версия ghc, .T -serial (обычно %nil).
требующих каждая свой ghcXYZ(.T). ghc при этом придется перевести
на альтернативы.

Виртуальных Provides: вида ghc-zlib НЕ БУДЕТ. Вместо этого
BuildRequires: будут вычисляться при сборке, макросом.

У приложений будет написано
BuildRequires: %{ghcdep zlib utf8-string ...}
которые в зависимости от содержимого rpm-build-ghc
будут при сборке раскрываться в конкретные
ghcXYZ(.T)-zlib, ghcXYZ(.T)-utf8-string, ghcXYZ(.T)-...

При обновлении сначала неспеша собираем новый ghc и библиотеки к нему.
Затем меняем rpm-build-ghc и неспеша пересобираем приложения.

Те приложения, которые с новым набором ghc+libs собираться
упорно не хотят, оставляем собираться со старым набором,
явно загружая при сборке rpm-build-ghc-compat-ABC(.D).

Инструменты для автоматизированной правки спеков я напишу и предоставлю.

Как такой вариант? 

-- 

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