[newbies] Вопросы по укладке ghc разных версий в gear

[Ivan Zakharyaschev]

On Mon, 28 May 2018, Eugine Kosenko wrote:

> При попытке уложить экосистему ghc в gear возник ряд вопросов.
> 
> Прежде всего, не совсем понятно, когда стоит выделять ghc определенной
> версии в отдельное хранилище git?
> 
> Скажем, у меня собираются ghc версий 7.6.1, 7.10.1, 8.0.2, 8.2.2 и 8.4.2, и
> все они могут быть поставлены в систему одновременно, а переключение между
> ними производится через альтернативы либо через ghc_wrapper, который берет
> версию из переменной окружения.
> 
> Так много версий нужно, потому что 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 это пока
> невозможно (ну или, у меня это пока не получилось).
> 
> Ситуация очень похожа на ситуацию с 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?

Если коротко на этот вопрос отвечать, то получается так: в /gears/ 
создаются репозитории по имени каждого исходного пакета. Если в Sisyphus 
есть несколько пакетов, то и у каждого из них должен быть свой исходный.

Мейнтейнер при этом может для своего удобства работать с одним 
git-репозиторием (и может один иметь в /people/).

git-репозитории gcc* скорее всего имеют часть общей истории, потому что с 
ними так и происходит.

> И получается, что сейчас проще всего завести по отдельному хранилищу git
> для каждой версии ghc, но тогда мы теряем кучу преимуществ, которые дает
> нам хранение исходников в git.
> 
> И вообще, казалось бы логичным собрать весь этот зоопарк в одном хранилище
> git, и промаркировать отдельные версии. И для каждой ветки (или метки)
> всего лишь модифицировать спек таким образом, чтобы он из одного и того же
> подкаталога исходников в своей ветке формировал пакет с соответствующим
> именем. Например, один и тот же ghc.spec для одного и того же подкаталога
> исходников ghc в зависимости от ветки собирал бы пакеты ghc7.6.1, ghc7.10.1
> и так далее? Можно ли такое сделать в gear? И если можно, то почему так не
> сделано для gcc? Не связано ли это с тем, что система сборки репозитария,
> скажем, Сизифа, не может догадаться, какие ветки хранилища git собирать,
> чтобы получить все пакеты, доступные для установки в системе? Но мне

Все версии сразу не собирают. Но для каждой отдельной сборки можно указать 
свой тег, а внутри коммита по этому тегу будет лежать .gear/rules, где 
можно указать tree-ish (тег или коммит и путь), откуда брать исходники.

> кажется, такие подсказки сборщику вполне можно было бы дать. Или это очень
> сложно реализовать?
> 
> Есть еще один сложный вопрос по поводу того, что отдельные пакеты ghc могут
> одновременно собираться в для нескольких веток компилятора. Я не нашел
> такой аналогии в gcc (там версия glibc, как я понял, жестко привязана к
> версии gcc; или нет?). И мне непонятно, как в таком случае управлять
> спеками для таких пакетов. Но лучше пока разобраться с теми вопросами,
> которые я уже задал.

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

При желании можно было бы собрать отдельный пакет под конкретную версию 
компилятора дополнительно (жёстко зафиксировав версию ghc в этом варианте 
спека; т.е. такой форк пакета произошёл бы).