LINUX.ORG.RU

Раскуроченные зависимости кабало-пакетов

 ,


0

2

Требую показательный брифинг на тему кабала, кабал-дева и юзания ебилдов из haskell-overlay.

Вот, допустим, стандартная ситуация для среднего юзера вышеупомянутого оверлея.

$> cabal-dev install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: loh-0.0.0 (user goal)
trying: hslogger-1.2.0/installed-677... (dependency of loh-0.0.0)
trying: unordered-containers-0.2.2.0/installed-ae8... (dependency of
loh-0.0.0)
next goal: time (dependency of loh-0.0.0)
rejecting: time-1.4.0.1/installed-c2f... (conflict: unordered-containers =>
deepseq==1.3.0.1/installed-4c6..., time => deepseq==1.3.0.0/installed-c26...)
rejecting: time-1.4/installed-d61..., 1.4.0.1, 1.4, 1.3, 1.2.0.5, 1.2.0.4,
1.2.0.3, 1.2.0.2, 1.2.0.1, 1.2, 1.1.4, 1.1.3, 1.1.2.4, 1.1.2.3, 1.1.2.2,
1.1.2.1, 1.1.2.0, 1.0 (conflict: hslogger => time==1.4.0.1/installed-c2f...)

Почему-то deepseq вдруг стал 1.3.0.1, а зачем? Ах, точно же, это обычный дипсек, только подкостыленный для ghc-7.6.

Вопрос 1: почему пакетики для гхц-7.6 уже в оверлее, если самого гхц-7.6 ещё нет?

Ну ок, допустим я догадался, что дело в дипсеке, даунгрейднул его до 1.3.0.0, пересобрал 59 пакетов от него зависящих и вроде всё заработало.

Вопрос 2: а чего вдруг кабал-дев смотрит на глобальные пакеты, их версии и зависимости? Если я правильно понимаю суть кабал-дева, он должен быть наставить недостающих пакетиков в локальный энвайронмент и юзать их оттуда.

Уважаемые знатоки ( qnikst), расскажите, в чём вообще разница между кабалом и кабал-девом в случае использования пакетиков из оверлея?

Я бы ещё спросил, как сделать рабочее окружение вокруг, например, ghc-7.0.4 при политике удаления старых ебилдиков в оверлее, но это уже, наверное, перебор.

★★

Последнее исправление: dmitry_malikov (всего исправлений: 1)

Вопрос 1: почему пакетики для гхц-7.6 уже в оверлее, если самого гхц-7.6 ещё

нет?

как это нет, ктож его спрятал-то? И кстати уже почти юзабельный, всего-лишь порядка 74 пакетов осталось пофиксить :).

Вопрос 2: а чего вдруг кабал-дев смотрит на глобальные пакеты, их версии и зависимости? Если я правильно понимаю суть кабал-дева, он должен быть наставить недостающих пакетиков в локальный энвайронмент и юзать их оттуда.

кабал дев смотрит на наличие глобальных пакетов, и если там чего не хватает, то докачивает зависимости, и так же с конфликтующими. Но, есть проблемка, смотрит он не пофикшенные пакеты, коих уже достаточно много, а те, что на hackage, и возможно криво определяет зависимости.

Я бы ещё спросил, как сделать рабочее окружение вокруг, например, ghc-7.0.4 при политике удаления старых ебилдиков в оверлее, но это уже, наверное, перебор.

в оверлее очень простая политика, поддерживаются максимальная констистентная система пакетов, проверяется на ghc-7.0.4, ghc-7.4.*, 7.5 (? спрашивай gienah), 7.6.1, 7.7 (спрашивай gienah) если щас что и поломали, спрашивай то зайди на #gentoo-haskell и спроси.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

как это нет, ктож его спрятал-то? И кстати уже почти юзабельный, всего-лишь порядка 74 пакетов осталось пофиксить :).

Нет кейвордов ⇒ нет пакета.

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

А кабал, запущенный не от рута, инсталлирует пакеты в то же глобальное месиво, или отдельно?

Ну и да. Кабал-дев нашёл установленные пакеты, зависящие от разных версий дипсека. Вывести, что дипсек-1.3.0.0 всех устроит, у него не получилось.
Вопрос - зачем ориентироваться на установленные версии пакетов? Экономия времени, чтобы не пересобирать весь хакадж на каждом кабал-инсталле? Не смотрел бы кабал-дев на установленный дипсек-1.3.0.1, то он никогда бы про него и не узнал, ошибки бы не возникло.

в оверлее очень простая политика, поддерживаются максимальная констистентная система пакетов, проверяется на ghc-7.0.4, ghc-7.4.*, 7.5 (? спрашивай gienah), 7.6.1, 7.7 (спрашивай gienah)

То есть, вы гарантируете, что для каждого пакета в оверлее есть версия, собирающаяся под каждой из указанных версий компилятора?

dmitry_malikov ★★
() автор топика
Ответ на: комментарий от dmitry_malikov

Нет кейвордов ⇒ нет пакета.

с чего бы это кейвордить пакеты, работающие на других ghc?

А кабал, запущенный не от рута, инсталлирует пакеты в то же глобальное месиво, или отдельно?

в ~/.cabal - большого смысла не вижу правда

Вопрос - зачем ориентироваться на установленные версии пакетов? Экономия времени, чтобы не пересобирать весь хакадж на каждом кабал-инсталле? Не смотрел бы кабал-дев на установленный дипсек-1.3.0.1, то он никогда бы про него и не узнал, ошибки бы не возникло.

да. да, кстати офигенно помогает. У тебя есть 3 способа решить проблему, 1). использовать ghc-7.0 / ghc-7.4, как я понимаю такая проблема только с 7.6 должна быть, 2). ты можешь поставить все пакеты, которые хочет cabal-dev в систему, 3). ты можешь курить флаги кабал-дева, как игнорировать системные пакеты, или поставить всё вручную (хотя на самом деле тебе хватит cabal-dev install deepseq-нужной версии).

То есть, вы гарантируете, что для каждого пакета в оверлее есть версия, собирающаяся под каждой из указанных версий компилятора?

7.5, 7.7 - естественным образом негарантируется ничего, т.к. это тестовые ветки, в остальном стремимся к этому, и если что не так, то weclome на #irc канал, всё равно тут тебе врятли предложат адекватную идею (кроме перехода на nixOs, или добавления толпы хаков).

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Под отсутствием пакета подразумевается следующее:

#> eix -e ghc
[I] dev-lang/ghc
     Available versions:  (~)6.10.4-r1 (~)6.10.4-r1[1] 6.12.3 6.12.3[1] 6.12.3-r2 6.12.3-r2[1] (~)7.0.4 (~)7.0.4[1] (~)7.4.1 (~)7.4.1[1] (~)7.4.1-r1 (~)7.4.1-r1[1] (~)7.4.2[1] **7.5.20120615[1] **7.5.20120711[1] **7.5.20120718[1] **7.7.20120806[1] **9999[1] {{bash-completion binary doc (+)ghcbootstrap ghcmakebinary ghcquickbuild llvm}}
     Installed versions:  7.4.2[1](03:55:45 AM 08/04/2012)(doc -binary -ghcbootstrap -ghcmakebinary -llvm)
     Homepage:            http://www.haskell.org/ghc/
     Description:         The Glasgow Haskell Compiler

использовать ghc-7.0 / ghc-7.4, как я понимаю такая проблема только с 7.6 должна быть

Текущая версия гхц - 7.4.2

dmitry_malikov ★★
() автор топика
Ответ на: комментарий от dmitry_malikov

eix-update?

[I] dev-lang/ghc
     Available versions:  (~)6.10.4-r1 (~)6.10.4-r1[1] 6.12.3 6.12.3[1] 6.12.3-r2 6.12.3-r2[1] (~)7.0.4 (~)7.0.4[1] (~)7.4.1 (~)7.4.1[1] (~)7.4.1-r1 (~)7.4.1-r1[1] (~)7.4.2[1] (**)7.6.1[1] [m](**)7.7.20120806[1] [m](**)9999[1] {{bash-completion binary doc (+)ghcbootstrap ghcmakebinary ghcquickbuild llvm}}
     Installed versions:  7.6.1[1](02:18:23 12.09.2012)(doc ghcbootstrap -binary -ghcmakebinary -llvm)
     Homepage:            http://www.haskell.org/ghc/
     Description:         The Glasgow Haskell Compiler
qnikst ★★★★★
()
Ответ на: комментарий от dmitry_malikov

отлично.

ну и чтобы тут отметиться, deepseq поправили.

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.