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

[Eugine Kosenko]

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

Возможно, это не comme il faut с точки зрения управления пакетами, но у
меня такая же ситуация с Emacs MELPA --- я предпочитаю ставить модули Emacs
через нее, а не через rpm. И то же самое было с cabal и node, хотя
последний я пока всерьез не разворачивал.

сб, 6 квіт. 2019 о 16:56 Eugine Kosenko <eugine.kosenko на gmail.com> пише:

> Для обновления модулей у нас предусмотрен инструмент cabal2rpm, с
>>> помощью него удобно получить полный набор gear-репозиториев под все
>>> новые модули. С ходу я от него не добился двух вещей - правильной
>>> генерации сборочных зависимостей и обновления уже собраных модулей.
>>> Кроме того cabal2rpm предполагает, что ему передают тарболы с
>>> модулями, а это уже не рабочий вариант, как оказалось.
>>>
>>
>> У меня есть комплект самописных скриптов на fish, которые позволяют
>> выстраивать нужные зависимости и собирать массово нужные пакеты. Правда,
>> все это "на коленке". Если интересно, постараюсь на выходные привести все в
>> порядок и выложить "как есть".
>>
>
> В общем, пересмотрел свои инструменты. Я беру зависимости из конкретно
> выбранного плана сборки для выбранного снапшота stackage. Задаю в рамках
> этого плана один или несколько модулей-целей. Потом с помощью самописной
> утилиты на haskell вытягиваю все зависимости из плана сборки и упорядочиваю
> все необходимые пакеты в виде списка имен и версий пакетов, которые нужно
> собрать.
>
> А потом уже с помощью fish-скриптов собираю последовательно все пакеты и
> устанавливаю их в систему. Для каждого пакета из списка вытягиваю его из
> хранилища, создаю две копии --- оригинал и измененную, делаю нулевой патч
> (позже объясню, зачем) и генерирую spec-файл с помощью cabal2rpm. Потом я
> делаю сборку дважды: при первом проходе в spec-файл добавляются зависимости
> с помощью банального buildreq, а затем уже производится финальная сборка.
> После этого пакет ставится в системе, и происходит переход к следующему
> пакету. Процесс в общем медленный, а спеки, может быть, немного грязные, но
> в целом все достаточно надежно. Автоматически было собрано около 90% всех
> пакетов.
>
> В остатке проблемы только в трех случаях. Во всех трех ситуациях проще
> было исправить все вручную, чем городить новые автоматы. Во-первых, это
> пакеты, у которых имена содержат прописные буквы (HUnit, QuickCheck).
> Во-вторых, в нескольких местах глючил cabal2rpm. Эту проблему сейчас
> повторить не удалось, а запускать весь процесс заново, только чтобы поймать
> эти модули считаю пока нецелесообразным. И, наконец, некоторое количество
> cabal-файлов содержат неправильную информацию о версиях зависимостей.
> Поэтому я бы не полагался так сильно на возможности cabal и cabal2rpm. В
> последнем случае я вручную проверял правильные зависимости по сайту
> hackage.haskell.org, и изменял версии прямо в cabal-файле в каталоге с
> измененной версией. После этого повторял сборку, которая автоматически
> строила нужный патч на cabal-файл. Неудобно, но мне хватило терпение
> сделать все это руками.
>
> Если интересно, могу выложить исходники утилиты для получения списка
> сборки и скрипты. Утилита более-менее задокументирована, а вот скрипты могу
> дать только "как есть". Просто не понимаю, нужно ли их вообще "причесывать".
>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20190406/4024d0b0/attachment.html>