[devel] GHC-7.4
Igor Vlasenko
vlasenko на imath.kiev.ua
Пт Фев 10 01:22:50 MSK 2012
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
Подробная информация о списке рассылки Devel