[devel] GHC-7.4

[devel] GHC-7.4

[Vitaly Kuznetsov]

Hi,

в связи с выходом ghc-7.4.1 задумался о переезде Сизифа на эту версию. 
Наши коллеги из debian уже сделали это в unstable.
Есть ли противопоказания?

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Mon, Feb 06, 2012 at 10:34:34AM +0400, Vitaly Kuznetsov wrote:

VK> в связи с выходом ghc-7.4.1 задумался о переезде Сизифа на эту версию. 
VK> Наши коллеги из debian уже сделали это в unstable.
VK> Есть ли противопоказания?

Я бы очень хотел внедрить поддержку нескольких версий ghc, аналогично gcc.
Ибо с новым ghc часто не собирается много старого добра. У меня пока не
хватает времени чтобы сделать это, но активную помощь если возьмешься
обещаю.

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Vitaly Kuznetsov]

On Mon, 6 Feb 2012 12:22:18 +0400, Денис Смирнов wrote:
> On Mon, Feb 06, 2012 at 10:34:34AM +0400, Vitaly Kuznetsov wrote:
>
> VK> в связи с выходом ghc-7.4.1 задумался о переезде Сизифа на эту 
> версию.
> VK> Наши коллеги из debian уже сделали это в unstable.
> VK> Есть ли противопоказания?
>
> Я бы очень хотел внедрить поддержку нескольких версий ghc, аналогично 
> gcc.
> Ибо с новым ghc часто не собирается много старого добра. У меня пока 
> не
> хватает времени чтобы сделать это, но активную помощь если возьмешься
> обещаю.

Трезво оценивая имеющиеся на околохаскельные дела ресурсы плюрализм не 
кажется мне хорошей идеей.

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Mon, Feb 06, 2012 at 02:01:02PM +0400, Vitaly Kuznetsov wrote:

VK> Трезво оценивая имеющиеся на околохаскельные дела ресурсы плюрализм не 
VK> кажется мне хорошей идеей.

Именно поэтому она и хорошая. Потому как сборка нового хаскеля (и
обновление библиотек), при том что в репо есть пакеты, требующие хаскеля
для сборки -- это целое представление. Я в свое время делал один подход к
7.0 и отступил.

При наличии же параллельных версий, эта проблема решается вполне
тривиально.

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Igor Vlasenko]

On Mon, Feb 06, 2012 at 05:51:49PM +0400, Денис Смирнов wrote:
> On Mon, Feb 06, 2012 at 02:01:02PM +0400, Vitaly Kuznetsov wrote:
> 
> VK> Трезво оценивая имеющиеся на околохаскельные дела ресурсы плюрализм не 
> VK> кажется мне хорошей идеей.
> 
> Именно поэтому она и хорошая. Потому как сборка нового хаскеля (и
> обновление библиотек), при том что в репо есть пакеты, требующие хаскеля
> для сборки -- это целое представление. Я в свое время делал один подход к
> 7.0 и отступил.
> 
> При наличии же параллельных версий, эта проблема решается вполне
> тривиально.

Хотел бы предложить помощь. Могу заскриптовать работу с srpm пакетами 
для поддержки нескольких версий ghc. Еще в прошлом году собирался
так сделать, но попал в положение Буриданова осла, когда 
было несколько вариантов, как это будет выглядеть на практике,
со своими достоинствами и недостатками, и так и не выбрал, как 
должно выглядеть multighc полиси.

Т.е. надо выбрать схему работы, а я ее с удовольствием заскриптую.

-- 

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

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Mon, Feb 06, 2012 at 05:32:55PM +0200, Igor Vlasenko wrote:

IV> Хотел бы предложить помощь. Могу заскриптовать работу с srpm пакетами 
IV> для поддержки нескольких версий ghc. Еще в прошлом году собирался
IV> так сделать, но попал в положение Буриданова осла, когда 
IV> было несколько вариантов, как это будет выглядеть на практике,
IV> со своими достоинствами и недостатками, и так и не выбрал, как 
IV> должно выглядеть multighc полиси.
IV> Т.е. надо выбрать схему работы, а я ее с удовольствием заскриптую.

А какие варианты ты преддполагаешь?

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Igor Vlasenko]

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

Re: [devel] GHC-7.4

[Vitaly Kuznetsov]

On Thu, 9 Feb 2012 23:22:50 +0200, Igor Vlasenko wrote:
> Подумав еще раз, выбрал и хочу предложить следующее:
>
> Каждое приложение (вроде 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).
>
> Инструменты для автоматизированной правки спеков я напишу и 
> предоставлю.
>
> Как такой вариант?

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

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

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

Re: [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

Re: [devel] GHC-7.4

[Igor Vlasenko]

On Fri, Feb 10, 2012 at 06:49:30PM +0200, Igor Vlasenko wrote:
> Я тоже сначала думал о таких подходах, но если спеки самих
> пакетов не менять, то у нас сразу же возникает шаг 4)
> выше -- обязательная всеобщая пересборка. 
> А всеобщая пересборка -- вещь очень коварная, когда семеро одного ждут.
> Если у нас 20 ghc пакетов -- этот аспект не заметен.
> Если у нас 90 ghc пакетов, как сейчас - это еще терпимо.
> Но если у нас будет 900 ghc пакетов (не обязательно в Сизифе;
> может быть, в отдельной песочнице автоимпорта из Hackage)
> то необходимость всеобщей пересборки на шаге 4) обязательно
> выстрелит в ногу и рано или поздно парализует работу.
> 
> Вспомним героические усилия для обновления питона.

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

-- 

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

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Fri, Feb 10, 2012 at 07:54:34PM +0200, Igor Vlasenko wrote:

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

Я считаю что исходные пакеты должны содержать в себе номер версии хаскеля,
с которым они собираются. Это очень грязный хак, но другого способа
поддерживать в репозитории две версии хаскеля одновременно я себе не
представляю.

Так что редактирование спеков делать придется :(

Правда жизнь облегчается тем, что сборка из hackage в rpm крайне простая,
мой cabal2gear с этим справляется прекрасно (разве что не умеет сам
сборочные зависимости проставлять).

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Igor Zubkov]

2012/2/11 Денис Смирнов:
> On Fri, Feb 10, 2012 at 07:54:34PM +0200, Igor Vlasenko wrote:
>
> IV> Впрочем, я не утверждаю, что изложенный выше подход
> IV> самый правильный. У каждого подхода свои плюсы и минусы.
> IV> Но что-то выбрать надо.
>
> Я считаю что исходные пакеты должны содержать в себе номер версии хаскеля,
> с которым они собираются. Это очень грязный хак, но другого способа
> поддерживать в репозитории две версии хаскеля одновременно я себе не
> представляю.
>
> Так что редактирование спеков делать придется :(
>
> Правда жизнь облегчается тем, что сборка из hackage в rpm крайне простая,
> мой cabal2gear с этим справляется прекрасно (разве что не умеет сам
> сборочные зависимости проставлять).

Это этому скрипту мы обязаны за кривые урлы в ghc-пакетах?

http://packages.altlinux.org/en/search?utf8=✓&branch=Sisyphus&query=ghc

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Sat, Feb 11, 2012 at 01:04:21AM +0200, Igor Zubkov wrote:

IZ> Это этому скрипту мы обязаны за кривые урлы в ghc-пакетах?
IZ> http://packages.altlinux.org/en/search?utf8=✓&branch=Sisyphus&query=ghc

Да :)

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Igor Vlasenko]

On Sat, Feb 11, 2012 at 02:52:39AM +0400, Денис Смирнов wrote:
> On Fri, Feb 10, 2012 at 07:54:34PM +0200, Igor Vlasenko wrote:
> 
> Я считаю что исходные пакеты должны содержать в себе номер версии хаскеля,
> с которым они собираются. Это очень грязный хак, но другого способа
> поддерживать в репозитории две версии хаскеля одновременно я себе не
> представляю.
> 
> Так что редактирование спеков делать придется :(

В общем, при любой схеме нужна возможность ставить рядом несколько ghc.
Думаю, с этого надо начать, если это еще не сделано.

-- 

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

Re: [devel] GHC-7.4

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Sat, Feb 11, 2012 at 08:54:07PM +0200, Igor Vlasenko wrote:

IV> В общем, при любой схеме нужна возможность ставить рядом несколько ghc.
IV> Думаю, с этого надо начать, если это еще не сделано.

Нужно реализовать схему аналогичную gcc, только у меня силенок не хватает
ее осознать.

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] GHC-7.4

[Денис Смирнов]

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/
----------------------------------------------------------------------------

Re: [devel] GHC-7.4

[Igor Vlasenko]

Сорри, приболел, реагирую с запаздыванием.

On Mon, Feb 13, 2012 at 07:06:30PM +0400, Денис Смирнов wrote:
> IV> Подумав еще раз, выбрал и хочу предложить следующее:
> IV> Каждое приложение (вроде xmonad) в установленной системе одно,
> IV> Библиотек (вроде ghc-zlib) в системе может быть несколько,
> IV> неконфликтующих, равноправных, с названиями 
> IV> ghcXYZ(.T)-zlib, где XYZ - версия ghc, .T -serial (обычно %nil).
> IV> требующих каждая свой ghcXYZ(.T). ghc при этом придется перевести
> IV> на альтернативы.
> 
> Для чего serial?
Для следующего, прошу поправить, если не так понимаю.
Даже если версия XYZ не изменилась, при необходимости внести
изменения в ghc полетят его provides -

diff -u rebuild_provides sisyphus_provides
...
 ghc7.0.1(time) = 1.2.0.3
-ghc7.0.1(time-1.2.0.3-edf96900354f64de48284c95dbf6029a)  
+ghc7.0.1(time-1.2.0.3-9dc693ae41bc4a79faf2339f8923a2c4)  
 ghc7.0.1(unix) = 2.4.1.0
-ghc7.0.1(unix-2.4.1.0-13f44222715caac4bba717310d1dd2e6)  
+ghc7.0.1(unix-2.4.1.0-f61f2ddea759757341ca757be499cab8)  
 ghc = 7.0.1-alt1
и т.д.
И для нового релиза ghcXYZ придется вместе с ним пересобирать
все пакеты, а мы пытаемся уйти от гигантских транзакций.
Вот чтобы и не требовалась тотальная пересборка, и нужен
ghc_serial, который по умолчанию %nil и не виден,
но если понадобится (например, с патченным ghc сборка чего-то
отвалилась) то он есть.
 
> 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> Затем меняем rpm-build-ghc и неспеша пересобираем приложения.
> Гм, а почему меняем rpm-build-ghc? Ради ghcdep?

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

Поддерживаю любую реализацию.


-- 

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

Re: [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

Re: [devel] GHC-7.4

[Igor Vlasenko]

On Tue, Feb 14, 2012 at 02:19:40PM +0200, Igor Vlasenko wrote:
> Это в старой парадигме мы все пересобираем (гигантскими) транзакциями.
> В новой мы все собираем рядом.

Чтобы понять разницу в подходах, применим подход 
"редукция к абсурду". Представим, что подход "один ghc, одна библиотека"
процвел и в Сизифе появилась подсистема haskell на 1000 пакетов.

Что это будет? Подсистема python'а по сравнению с ней - 
детский сад. С питоном большую часть времени можно спокойно работать,
только раз в год надо обновить питон. Тогда надо призвать
былинного богатыря, который сбросит в incoming гигантского
змия-транзакцию на 1000 пакетов, от которой неделю будет
содрогаться сборочница и стонать майнтайнеры.
После чего все дружно возликуют и будут спокойно жить еще год.

А haskell при подходе "один ghc, одна библиотека" -- это питон,
в котором былинного богатыря надо призывать на каждое обновление
любого питоньего модуля.

-- 

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