[SOLVED] Конфликт пакетов после даунгрэйда

После установки некоторого пакета он потянул за собой даунгрэйд пакета swig c версии 3.0.5 до версии 2.0.9

в результате это привело к конфликту

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
dev-lang/swig:0

  (dev-lang/swig-3.0.5:0/0::gentoo, ebuild scheduled for merge) conflicts with
    <=dev-lang/swig-3.0.4 required by (sci-libs/gdal-1.11.1-r3:0/0::gentoo, installed)
    ^^              ^^^^^

Если portage не установил swig в другой слот, то как я понимаю такой возможности нет.

Посоветуйте пожалуйста как устранить возникший конфликт.

Kaкой пакет? Какие у него

Kaкой пакет? Какие у него требования к swig?
Может размаскировать/замаскировать определенные версии (найти компромиссный вариант) его и/или sci-libs/gdal поможет.

SysA написал(а):Kaкой пакет?

SysA написал(а):
Kaкой пакет? Какие у него требования к swig?
Может размаскировать/замаскировать определенные версии (найти компромиссный вариант) его и/или sci-libs/gdal поможет.

Конфликт появился после установки dev-db/mysql и dev-db/mysql-workbench. До установки этих пакетов при обновлении мира проблем не возникало.

Если посмотреть какие пакеты зависят от пакета swig то получается такая вот картина:

equery d swig
 * These packages depend on swig:
dev-db/mysql-workbench-6.3.4-r1 (dev-lang/swig)
dev-libs/libnl-3.2.27 (python ? dev-lang/swig)
sci-libs/gdal-1.11.1-r3 (perl ? >=dev-lang/swig-2.0.2)
                        (perl ? <=dev-lang/swig-3.0.4)
                        (python ? >=dev-lang/swig-2.0.2)
                        (python ? <=dev-lang/swig-3.0.4)
                        (ruby ? >=dev-lang/swig-2.0.2)
                        (ruby ? <=dev-lang/swig-3.0.4)
sci-libs/scipy-0.16.1 (dev-lang/swig)
sys-libs/libcap-ng-0.7.7 (python ? >=dev-lang/swig-2)

Получается, что dev-db/mysql тут вообще не причем, а dev-db/mysql-workbench использует dev-lang/swig-3.0.5 и ему даунгрейд не нужен.

equery g mysql-workbench-6.3.4-r1 | grep swig
 [  1]  dev-lang/swig-3.0.5

А вот эту запись я не понимаю и именно здесь устанавливается ограничение на swig версии выше 2.0.2, но ниже 3.0.4.

sci-libs/gdal-1.11.1-r3 (perl ? >=dev-lang/swig-2.0.2)
                        (perl ? <=dev-lang/swig-3.0.4)
                        (python ? >=dev-lang/swig-2.0.2)
                        (python ? <=dev-lang/swig-3.0.4)
                        (ruby ? >=dev-lang/swig-2.0.2)
                        (ruby ? <=dev-lang/swig-3.0.4)

Вероятно, что dev-db/mysql потянула perl и ruby (сам я их не ставил), а вот с ними уже конфликт. Python живет уже давно и все до сих пор было гладко.

georgedvo написал(а):
Попробовать установить более новую версию gdal.
Не смотря на тильду, вы можете получить вполне работоспособную конфигурацию.
Такие ситуации отнюдь не единичны.

sci-libs/gdal установлена стабильная версия 1.11.1-r3. Можно конечно попробовать поставить ~1.11.2 ~2.0.0 ~2.0.0-r1 ~2.0.1 ~2.0.2, но это наверное крайний вариант если не будет другого решения. Стараюсь ставить только стабильные пакеты.

Попробуй пересобрать

Попробуй пересобрать конфликтные пакеты с

-1 --nodeps

Если твой sci-libs/gdal устраивает любой dev-lang/swig, то это должно решить проблему.

SysA написал(а):Попробуй

SysA написал(а):
Попробуй пересобрать конфликтные пакеты с

-1 --nodeps

Если твой sci-libs/gdal устраивает любой dev-lang/swig, то это должно решить проблему.

Спасибо, возможно это не плохой вариант.

Во всем виноват был dev-db/mysql-workbench, который в прямой зависимости имеет и gdal-1.11.1-r3 и dev-lang/swig-3.0.5
НО! sci-libs/gdal-1.11.1-r3 потребовал понизить dev-lang/swig-3.0.5 до версии 2.0.2

сам же пакет gbal никто кроме mysql-workbench не использует, поэтому наверное и правда можно было бы поставить через emerge -1 --nodeps.

Получается, что возможные варианты:
1. Поставить gdal через emerge -1 --nodeps (перестанет кричать, что хочет понизить версию swig);
2. Ограничить версию swig не выше 3.0.0 в Portage (понизить версию swig до 2.0.2 и жить с этим);
3. Поставить нестабильную версию gdal и не трогать swig (и надеяться, что будет работать).

Решил пойти по 3-му варианту, в этом случае для меня не критично.

Всем спасибо, разобрался.

Попробовать установить более

Попробовать установить более новую версию gdal.
Не смотря на тильду, вы можете получить вполне работоспособную конфигурацию.
Такие ситуации отнюдь не единичны.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".