[devel] haskell в Сизифе

[devel] haskell в Сизифе

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

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

Хаскелевское хозяйство уже более-менее обновлено. Мне осталось написать
себе еще двух маленьких злобных роботов, после чего в плане свежести все
будет замечательно.

Но есть глобальные грабли.

1. Нужны жесткие зависимости на версии библиотек. Упрощенно можно считать
что при каждой сборке библиотеки у нее генерируется нечто вроде
уникального soname. Простая пересборка -- даст уже другой такой soname.

При этом если A собрано с C и B собрано с C, то чтобы собрать что-то что
требует и A и B в системе должны быть установлены A, B, C. Причем C ровно
той версии, с которой были собраны A и B.

Таким образом, если я просто сейчас пересоберу ghc (скажем захочу в
%description добавить пару слов), то после этого будет _необходимо_
пересобрать все библиотеки хаскеля.

В этом нет ничего страшного, если не считать того что это займет
сборочницу на полдня.

2. ghc очень динамично развивается. "Динамично" -- значит что код
прекрасно собирающийся с предыдущей версией может не собираться со
следующей минорной версией. Т.е. не все что собиралось на 6.10 будет
собираться на 6.12. Библиотеки развиваются примерно так же, причем не все
успевают следить за изменениями (например cabal-rpm сейчас не собирается).

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

Так как совместимость нарушается в обе стороны, становится очевидным
необходимость иметь в Сизифе несколько хаскеллей.

3. И напоследок самое интересное: 6.12 (который теперь у нас) умеет
собирать библиотеки динамически. Это хороший плюс (разница в размере
бинарника 3Mb или 30-50Kb заставляет задуматься).

Но негативные последствия куда веселее. Для работы собранного _так_
приложения необходимо чтобы в системе была установленна эта библиотека, да
еще и ровно той же версии (и релиза!) с которой был слинкован бинарник.

Если не ставить жестких зависимостей -- никто не гарантирует что после
очередного apt-get upgrade все хаскелевские динамически собранные
программы вдруг случайно не перестанут работать.

Если их ставить -- это будет извращенное издевательство над идеями моего
любимого SharedLibsPolicy.

Есть выход -- можно собирать shared libs в субпакет с _именем_ вида
libghc-%name-%version-%release. Тогда все будет хорошо, если не считать
того что после каждого apt-get upgrade в системе будет оставаться куча
мусорных никому не нужных библиотек.

Сделать такую конструкцию я вполне могу, но вот как автоматически
генерировать соответствующие зависимости (т.е. типа ghc(abc.so) = <id>) я
не представляю. 

4. Скоро надо будет отправлять в Сизиф еще и 6.14, и, как меня тут
обрадовали, возможно 7. Последний особенно интересен использованием LLVM
(на некоторых задачах до 30% ускорение сгенерированного кода).

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

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


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