Solaris IPS: pkg dependency errors bear no relation to actual issue / how best to diagnose IPS dependency failures?

Question

I am running Solaris 11.3 (at present from the non-contract Release repo). I have a large amount of Solaris 10 experience, but I am newer to 11 and am still working on getting confident with IPS.

My issue is that I regularly find I have severe problems diagnosing package dependency failures, because the output of pkg install seems to bear no relation to the actual problem. In fact I am now wondering if this is being caused by some bug or repository problem, as I'll explain at the end.

Below are two examples of recent problems I have faced where the output of a failed pkg command seems entirely unrelated to the real problem. In the first example this caused me to spend literally days chasing red herrings until I eventually stumbled upon the required fix.

The global version is Oracle Solaris 11.3.1.5.1 (pkg/entire version 0.5.11-0.175.3.1.0.5.1.) The global was installed from the USB text installer and since then I have version-unlocked and updated all the FOSS packages that were installed in the global by default (as per the Oracle docs here), and additionally installed a few extra support packages (vim, screen, tmux, etc.)

When writing this post I re-created both examples from the position of a freshly installed solaris-small-server zone, with no other changes; the FOSS updates I describe above have occurred only in the global, not in the zone used to re-run the following examples and capture the error output. The commands listed below are literally the first commands run in a test zone after it was created from the default zone AI manifest.

Example 1: I have been trying to install a working Gnome desktop in a non-global zone, without having to install packages in my global which I always want to keep lean and clean.

1. zlogin zone pkg install --accept -v solaris-desktop : fails because driver/audio/audio-usb says it must also be installed in the global zone.
2. I create a custom version of solaris-desktop called solaris-desktop-zone which removes all driver/* packages, and also any package that has dependency on the global (which I removed via a script that called pkg contents -mr on each package and removed any that referenced feature/package/dependency/self.) I install this to my local repo, which is a pkg/mirror clone of http://pkg.oracle.com/solaris/release/.
3. Installing my modified package results in the long list of dependency failures shown in this pastebin, which are seemingly mostly related to Python packages.
4. I spent literally a day working through these errors: manually and recursively analysing the various Python packages and their dependencies and removing any mention that of them that I could find in my solaris-desktop-zone package. Eventually I resorted to just removing packages in clumps until I found a version that would pass the Solver stage, and then worked backwards from there to identify the one package and finally understand the cause.

The solution? x11/server/xorg/driver/xorg-video which depends on an NVidia driver which also has the feature/package/dependency/self dependency. With hindsight I could have found this a lot quicker with a recursive search for that self dependency - ie check not only all the packages depended on by my solaris-desktop-zone package, but also all their dependencies. But of course I was caught in a grind, believing from the errors that the problem was to do with Python packages or packages dependent on them.

Example 2: gcc-5

zlogin testdesktop pkg install --accept -nv gcc-5 produces this output.

Again the same list of strange Python errors, and again the solution is entirely unrelated: I need to unlock some versions related to 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

This one I thankfully found quickly via Google (here on Unix StackExchange). But I was still left bemused because the diagnosis described by the person who answered it didn't match what I had seen - the pkg errors listed in his post gave an understandable description of the problem (Reason: This version is excluded by installed incorporation..). Mine has these unrelated Python errors again!

Now as I write this out I'm wondering if there's something weird going on at the moment in the Solaris 11.3 release repo, perhaps fixed by a SRU that I can't access until I get a contract. Maybe that's why I am getting these weird errors rather than understandable, debuggable ones?

In that regard I do note there might be something wrong related to Dbus Python - one of the errors I see in both examples relates to python-dbus-27, which I note is now an obsoleted package which contains only a dependency on dbus-python-27. But dbus-python-27 does not exist in the repo. So that might be a repo problem.

But even if so, why do I only see these errors when I have some other, completely unrelated problem? Is that a bug caused by a repo problem?

I would be grateful for confirmation as to whether that's the case, and in general to learn more about the suggested methods and tools for debugging and resolving package dependency problems. Given the errors I got, could I have resolved this quicker without resorting to brute-force checking of every dependent package?

Thanks in advance.

Answer 1

First, some configurations require installation of packages into the global zone if they are installed in the non-global zone. This is done by using 'parent' dependencies as I mentioned in another reply to you: Solaris 11.3 non-global zones not inheriting IPS facet changes (to version-lock)

This is generally true for the dependencies of the solaris-desktop package because it relies on services that only the global zone can run (since only the global zone has an actual kernel), such as drivers, NFS, or other specific services.

The 'no version' 'can be found' errors are fairly literal; it basically means that no version that satisfies the package dependency is in the configure repository.

Unfortunately, it looks like you've discovered a problem with some of the evaluation packages. You're not doing anything wrong, it just won't work right now. This is something that will have to be fixed internally first.

I don't think anyone has tested the combination of the base 11.3 release with the evaluation packages and attempted to install 'solaris-desktop' at the same time. This will take some time to resolve, so please be patient.

In the meantime, if you want a desktop-configured system, your best option is to not attempt to use the evaluation packages and to install solaris-desktop in the global zone first, and then the non-global zone. That is by far the simplest option.

The only way around this at the moment would be to modify and republish the packages that are giving you problems, but I cannot guide you through that process at the moment. Suffice to say, it would involve using pkgrecv --raw on each package you want to modify, then using pkgsend to republish each one to your own local repository.