Solaris IPS: ошибки зависимостей pkg не имеют никакого отношения к актуальной проблеме / как лучше всего диагностировать сбои зависимостей IPS?

Я использую Solaris 11.3 (в настоящее время из репозитория Release без контракта). У меня большой опыт работы с Solaris 10, но я новичок в 11 и все еще работаю над тем, чтобы стать уверенным в IPS.

Моя проблема в том, что я регулярно сталкиваюсь с серьезными проблемами при диагностике сбоев зависимостей пакетов, потому что вывод pkg install похоже, не имеет отношения к реальной проблеме. Фактически, теперь мне интересно, вызвано ли это какой-то ошибкой или проблемой репозитория, как я объясню в конце.

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

Глобальная версия - Oracle Solaris 11.3.1.5.1 (pkg/entire версия 0.5.11-0.175.3.1.0.5.1.) Глобальный файл был установлен из текстового установщика USB, и с тех пор я разблокировал версию и обновил все пакеты FOSS, которые были установлены в глобале по умолчанию (согласно Документы Oracle здесь) и дополнительно установил несколько дополнительных пакетов поддержки (vim, screen, tmux, и т.д.)

При написании этого поста я воссоздал оба примера с позиции только что установленного solaris-small-server зона, без других изменений; описанные выше обновления FOSS произошли только в глобальном масштабе, а не в зоне, используемой для повторного запуска следующих примеров и фиксации вывода ошибок. Перечисленные ниже команды - это буквально первые команды, запускаемые в тестовой зоне после того, как она была создана из манифеста AI зоны по умолчанию.

Пример 1: Я пытался установить рабочий стол Gnome в неглобальной зоне, без необходимости устанавливать пакеты в моей глобальной зоне, которую я всегда хотел бы сохранить компактной и чистой.

1. zlogin zone pkg install --accept -v solaris-desktop : терпит неудачу, потому что driver/audio/audio-usb говорит, что он также должен быть установлен в глобальной зоне.
2. Я создаю собственную версию solaris-desktop называется solaris-desktop-zone который удаляет все driver/* пакеты, а также любой пакет, зависящий от глобального (который я удалил с помощью скрипта, который вызвал pkg contents -mr на каждом пакете и удалил все, на которые есть ссылки feature/package/dependency/self.) Я устанавливаю это в свое локальное репо, которое pkg/mirror клон http://pkg.oracle.com/solaris/release/.
3. Установка моего измененного пакета приводит к отображению длинного списка сбоев зависимостей в этом пастебине, которые, по-видимому, в основном связаны с пакетами Python.
4. Я потратил буквально день, работая над этими ошибками: вручную и рекурсивно анализируя различные пакеты Python и их зависимости и удаляя любые упоминания о них, которые я мог найти в своих solaris-desktop-zone пакет. В конце концов я прибегал к простому удалению пакетов группами, пока не нашел версию, которая прошла бы стадию решателя, а затем работал в обратном порядке, чтобы идентифицировать один пакет и, наконец, понять причину.

Решение? x11/server/xorg/driver/xorg-video который зависит от драйвера NVidia, который также имеет feature/package/dependency/self зависимость. Оглядываясь назад, я мог бы найти это намного быстрее с помощью рекурсивного поиска этой самозависимости - т.е. проверять не только все пакеты, от которых зависел мой solaris-desktop-zone пакет, но и все их зависимости. Но, конечно, я был пойман в затруднительном положении, полагая по ошибкам, что проблема связана с пакетами Python или пакетами, зависящими от них.

Пример 2: gcc-5

zlogin testdesktop pkg install --accept -nv gcc-5 производит этот вывод.

Снова тот же список странных ошибок Python, и снова решение совершенно не связано: мне нужно разблокировать некоторые версии, связанные с GCC:

pkg change-facet version-lock.system/library/gcc/gcc-c-runtime=false \
version-lock.system/library/gcc/gcc-c++-runtime=false \
version-lock.system/library/gcc/gcc-gfortran-runtime=false \
version-lock.system/library/gcc/gcc-gobjc-runtime=false

К счастью, этот я быстро нашел через Google (здесь, на Unix StackExchange). Но я все еще был ошеломлен, потому что диагноз, описанный человеком, который ответил, не соответствовал тому, что я видел - ошибки pkg, перечисленные в его сообщении, дали понятное описание проблемы (Reason: This version is excluded by installed incorporation..). У меня снова есть эти несвязанные ошибки Python!

Сейчас, когда я пишу это, мне интересно, не происходит ли что-то странное в данный момент в репозитории релиза Solaris 11.3, возможно, исправленное SRU, к которому я не могу получить доступ, пока не получу контракт. Может быть, поэтому я получаю эти странные ошибки, а не понятные, отлаживаемые?

В этой связи я отмечаю, что может быть что-то не так, связанное с Dbus Python - одна из ошибок, которые я вижу в обоих примерах, связана с python-dbus-27, который, как я отмечаю, теперь является устаревшим пакетом, который содержит только зависимость от dbus-python-27. Но dbus-python-27 не существует в репо. Так что это может быть проблема репо.

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

Я был бы признателен за подтверждение того, так ли это, и в целом за то, чтобы узнать больше о предлагаемых методах и инструментах для отладки и решения проблем с зависимостями пакетов. Учитывая ошибки, которые я получил, мог ли я решить эту проблему быстрее, не прибегая к проверке грубой силы каждого зависимого пакета?

Заранее спасибо.