我正在运行 Solaris 11.3(目前来自非合同版本 repo)。我有大量的 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 docs here),并额外安装了一些额外的支持包(vim
、screen
、tmux
等)
在写这篇文章时,我从新安装的solaris-small-server
区域的位置重新创建了两个示例,没有其他更改;我上面描述的 FOSS 更新仅发生在全局中,而不发生在用于重新运行以下示例并捕获错误输出的区域中。下面列出的命令实际上是从默认区域 AI 清单创建后在测试区域中运行的第一个命令。
示例 1:我一直在尝试在非全局区域中安装一个正常工作的 Gnome 桌面,而不必在我的全局中安装我一直希望保持精简和干净的包。
zlogin zone pkg install --accept -v solaris-desktop
: 失败,因为driver/audio/audio-usb
说它还必须安装在全局区域中。- 我创建了一个
solaris-desktop
名为 called的自定义版本,solaris-desktop-zone
它删除了所有driver/*
包,以及任何依赖于全局的包(我通过调用pkg contents -mr
每个包的脚本删除了它并删除了任何引用的包feature/package/dependency/self
。)我将它安装到我的本地 repo,它是.pkg/mirror
_http://pkg.oracle.com/solaris/release/
- 安装我修改过的包会导致这个 pastebin中显示的一长串依赖失败,这些似乎主要与 Python 包有关。
- 我花了一天的时间来解决这些错误:手动和递归地分析各种 Python 包及其依赖项,并删除我在
solaris-desktop-zone
包中可以找到的任何提及它们的内容。最终,我只好删除成群的包,直到找到一个可以通过 Solver 阶段的版本,然后从那里向后工作以识别一个包并最终了解原因。
解决方案? x11/server/xorg/driver/xorg-video
这取决于也具有feature/package/dependency/self
依赖关系的 NVidia 驱动程序。事后看来,我可以通过递归搜索该自依赖来更快地发现这一点 - 即不仅检查我的包所依赖的所有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
在 repo 中不存在。所以这可能是一个回购问题。
但即使是这样,为什么我只有在遇到其他完全不相关的问题时才会看到这些错误?这是由回购问题引起的错误吗?
我将不胜感激确认是否是这种情况,并且总体上了解有关用于调试和解决包依赖性问题的建议方法和工具的更多信息。鉴于我得到的错误,我是否可以在不诉诸暴力检查每个依赖包的情况下更快地解决这个问题?
提前致谢。