Re: [devel] Обновление GHC

[Evgeny Sinelnikov <sin@altlinux.org>]

Здравствуйте,

сб, 6 апр. 2019 г. в 18:15, Eugine Kosenko <eugine.kosenko@gmail.com>:
>
> И еще есть подозрение, что после установки в системе stack никаких модулей больше не понадобится. У меня stack, даже после того, как я собрал и установил в системе yesod, все-равно пересобрал часть пакетов в свой собственный слой. Я так и не понял, чем ему не понравился системный yesod и некоторые пакеты, что он использует. Кроме того, stack позволяет развернуть любой план, в котором будет любая версия ghc вплоть до 8.6.4.
>
> Возможно, это не comme il faut с точки зрения управления пакетами, но у меня такая же ситуация с Emacs MELPA --- я предпочитаю ставить модули Emacs через нее, а не через rpm. И то же самое было с cabal и node, хотя последний я пока всерьез не разворачивал.
>

Дело не только "дурном" или "не дурном" стиле с точки зрения
управления пакетами. Дело в том, что предложение использовать,
например stack, как то, после чего "никаких модулей больше не
понадобится" - это подход разработчика. И сам GHC на это вполне
ориентирован.

Непонятно как сочетать этот подход "для разработчика" с подходом "для
пользователя". В этом ведь смысл дистрибутивных решений. Мы собрали
конечный код и хотим его передать пользователю. Зачем мне для этого
stack? Для того, чтобы в стиле Gentoo требовать от каждого
пользователя собирать у себя в домашнем каталоге конкретное
приложение?

А как быть с тем, чтобы это приложение легло в систему и было доступно
не только одному пользователю.

Я предлагаю в этом плане такой подход:
- Кроме GHC в сизифе необходимо обеспечить возможность инструментарий
для сборки приложений;
- Для возможности разработки необходимо обеспечить в сизифе
cabal-install и stack - по сути, оба эти инструмента имеют смысл, у
каждого из них есть своё сообщество и отдельный репозиторий:
https://www.stackage.org/
http://hackage.haskell.org/
- Подготовить для сборки приложений инструмент позволяющий генерацию
сборочных зависимостей с помощью cabal2gear.


> сб, 6 квіт. 2019 о 16:56 Eugine Kosenko <eugine.kosenko@gmail.com> пише:
>>>>
>>>> Для обновления модулей у нас предусмотрен инструмент cabal2rpm, с
>>>> помощью него удобно получить полный набор gear-репозиториев под все
>>>> новые модули. С ходу я от него не добился двух вещей - правильной
>>>> генерации сборочных зависимостей и обновления уже собраных модулей.
>>>> Кроме того cabal2rpm предполагает, что ему передают тарболы с
>>>> модулями, а это уже не рабочий вариант, как оказалось.
>>>
>>>
>>> У меня есть комплект самописных скриптов на fish, которые позволяют выстраивать нужные зависимости и собирать массово нужные пакеты. Правда, все это "на коленке". Если интересно, постараюсь на выходные привести все в порядок и выложить "как есть".

Да, было бы очень неплохо. Ещё было бы неплохо воспользоваться этими
инструментами для сборки cabal-install и stack, а также pandoc,
shellcheck, xmonad.




>>
>>
>> В общем, пересмотрел свои инструменты. Я беру зависимости из конкретно выбранного плана сборки для выбранного снапшота stackage. Задаю в рамках этого плана один или несколько модулей-целей. Потом с помощью самописной утилиты на haskell вытягиваю все зависимости из плана сборки и упорядочиваю все необходимые пакеты в виде списка имен и версий пакетов, которые нужно собрать.
>>
>> А потом уже с помощью fish-скриптов собираю последовательно все пакеты и устанавливаю их в систему. Для каждого пакета из списка вытягиваю его из хранилища, создаю две копии --- оригинал и измененную, делаю нулевой патч (позже объясню, зачем) и генерирую spec-файл с помощью cabal2rpm. Потом я делаю сборку дважды: при первом проходе в spec-файл добавляются зависимости с помощью банального buildreq, а затем уже производится финальная сборка. После этого пакет ставится в системе, и происходит переход к следующему пакету. Процесс в общем медленный, а спеки, может быть, немного грязные, но в целом все достаточно надежно. Автоматически было собрано около 90% всех пакетов.
>>
>> В остатке проблемы только в трех случаях. Во всех трех ситуациях проще было исправить все вручную, чем городить новые автоматы. Во-первых, это пакеты, у которых имена содержат прописные буквы (HUnit, QuickCheck). Во-вторых, в нескольких местах глючил cabal2rpm. Эту проблему сейчас повторить не удалось, а запускать весь процесс заново, только чтобы поймать эти модули считаю пока нецелесообразным. И, наконец, некоторое количество cabal-файлов содержат неправильную информацию о версиях зависимостей. Поэтому я бы не полагался так сильно на возможности cabal и cabal2rpm. В последнем случае я вручную проверял правильные зависимости по сайту hackage.haskell.org, и изменял версии прямо в cabal-файле в каталоге с измененной версией. После этого повторял сборку, которая автоматически строила нужный патч на cabal-файл. Неудобно, но мне хватило терпение сделать все это руками.
>>
>> Если интересно, могу выложить исходники утилиты для получения списка сборки и скрипты. Утилита более-менее задокументирована, а вот скрипты могу дать только "как есть". Просто не понимаю, нужно ли их вообще "причесывать".

Причёсывать сразу не обязательно. Давайте обновим пакеты, завершим
переезд и потом их "причешем". Ну, или посмотрим, может что-то и сразу
"причешем".




-- 
Sin (Sinelnikov Evgeny)