Re: [devel] GHC-7.4

["Денис Смирнов" <mithraen@freesource.info>]

On Thu, Feb 09, 2012 at 11:22:50PM +0200, Igor Vlasenko wrote:

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

Для чего serial?

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

Согласен. 

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

Да, это важно для сборки приложений (вроде xmonad).

Для остального -- так как версия ghc также будет и в %name, то можно в
buildrequires обойтись без макросов а указывать конкретные пакеты.

IV> При обновлении сначала неспеша собираем новый ghc и библиотеки к нему.

Да.

IV> Затем меняем rpm-build-ghc и неспеша пересобираем приложения.

Гм, а почему меняем rpm-build-ghc? Ради ghcdep?

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

Скорее юзая макрос типа %set_ghc_version (по аналогии с gcc).

Он будет важен потому, что если у нас одновременно установлено в системе
два ghc -- должен использоваться нужный.

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------