<div dir="ltr"><div><div><div><div><div>При попытке уложить экосистему ghc в gear возник ряд вопросов.<br><br></div>Прежде всего, не совсем понятно, когда стоит выделять ghc определенной версии в отдельное хранилище git?<br><br></div>Скажем, у меня собираются ghc версий 7.6.1, 7.10.1, 8.0.2, 8.2.2 и 8.4.2, и все они могут быть поставлены в систему одновременно, а переключение между ними производится через альтернативы либо через ghc_wrapper, который берет версию из переменной окружения.<br><br>Так много версий нужно, потому что 7.6.1 нужно для сборки 7.10.1, 7.10.1 --- для сборки 8.0.2, а 8.0.2 --- для сборки 8.2.2 и 8.4.1. При этом 8.2.2 и 8.4.1 собираются независимо, но для 8.2.2 собирается некоторая экосистема (скажем, stack, yesod и keter), в то время, как для 8.4.1 это пока невозможно (ну или, у меня это пока не получилось).<br><br></div>Ситуация очень похожа на ситуацию с gcc, где тоже есть каскадный бутстрап. И я очень многое пытаюсь сделать по образцу gcc. Но вот я вижу, что каждое поколение gcc имеет отдельное хранилище: gcc3.3, gcc3.4, ..., gcc6, gcc7. Тут непонятно, почему иногда выделена второе поле версии, а иногда нет? Неужели 3.3 и 3.4 настолько сильно отличались, что для них пришлось выделить отдельные пакеты? И как теперь стоит собрать версии ghc? Как 7.6, 7.10, 8.0, 8.2 и 8.4? Но ведь для сборки 8.4 не нужна 8.2?<br><br></div><div>И получается, что сейчас проще всего завести по отдельному хранилищу git для каждой версии ghc, но тогда мы теряем кучу преимуществ, которые дает нам хранение исходников в git.<br></div><div><br></div>И вообще, казалось бы логичным собрать весь этот зоопарк в одном хранилище git, и промаркировать отдельные версии. И для каждой ветки (или метки) всего лишь модифицировать спек таким образом, чтобы он из одного и того же подкаталога исходников в своей ветке формировал пакет с соответствующим именем. Например, один и тот же ghc.spec для одного и того же подкаталога исходников ghc в зависимости от ветки собирал бы пакеты ghc7.6.1, ghc7.10.1 и так далее? Можно ли такое сделать в gear? И если можно, то почему так не сделано для gcc? Не связано ли это с тем, что система сборки репозитария, скажем, Сизифа, не может догадаться, какие ветки хранилища git собирать, чтобы получить все пакеты, доступные для установки в системе? Но мне кажется, такие подсказки сборщику вполне можно было бы дать. Или это очень сложно реализовать?<br><br></div>Есть еще один сложный вопрос по поводу того, что отдельные пакеты ghc могут одновременно собираться в для нескольких веток компилятора. Я не нашел такой аналогии в gcc (там версия glibc, как я понял, жестко привязана к версии gcc; или нет?). И мне непонятно, как в таком случае управлять спеками для таких пакетов. Но лучше пока разобраться с теми вопросами, которые я уже задал.<br><div><br><br></div></div>